Some organizations have implemented Single Sign-On (SSO) without properly understanding the legal risks, providing the education to manage those risks, or putting in place the appropriate legal processes and documents. Such processes and documents should be in place and accepted by all of the SSO participants BEFORE utilizing SSO technologies.

My "sister company", Clareity Security, has added a number of important Single Sign-On (SSO) resources to its web site, especially for MLS operators, brokerages, and real estate software and settlement service providers implementing SSO. The most recent addition is a Single Sign-On Legal Compliance paper, prepared in consultation with noted attorney John H. Rees. Clareity Security is releasing this document to encourage real estate organizations implementing SSO to take the appropriate legal and business steps prior to implementation. Note that that document and the sample contract language are provided only as a resource, and are not intended to substitute for and do not constitute legal advice. 

The site also includes a video introduction to SSO and links to the SSO toolkit that software providers can use to implement SSO securely.

The SSO section of the Clareity Security web site, including links to all of the items mentioned above, is here: http://www.clareitysecurity.com/sso-video/

Background

Real estate professionals are using more systems and applications than ever, and they don’t want to have to log into each one separately. The inconvenience and inefficiency of multiple logins are exacerbated when users have to go back and forth between one system and another. As a result, system providers such as MLSs, transaction management software, larger brokerages and other real estate application vendors have moved to provide login integration of commonly used systems as a convenience for the users. This is referred to as Single Sign-On (SSO).

In order to improve the security and efficiency of implementing SSO, it was critical that the industry’s major software vendors agree on a standard method for doing so. This is why in August of 2005 Clareity Consulting published a free white paper, “The Convenience and Security of Single Sign-On” and subsequently facilitated two meetings, in December 2005 and March 2006, where many of the major MLS and transaction management vendors met to discuss how to achieve SSO in the real estate industry. MLS vendor attendees included Rob Overman, CTO of Fidelity MLS, Dan Mills, CTO of Interealty (First American MLS), Chip McAvoy, CTO at First American Residential Group (MarketLinx), Mike Wurzer, CEO/CTO of FBS, Carlos Grass, CEO of Stratus Data Systems, Brian de Shepper, CEO of Tarasoft, John Hensley, CTO of Homeseekers, and Brett Weiner, CTO/EVP of Rapattoni MLS.  It was critical to achieve cross MLS vendor support and cooperation, because while MLS may not be the center of the universe, imagine the decreased value of SSO without MLS system integration.  In addition to the key MLS software leaders, Cendant, CREA (Canadian Real Estate Association), OSCRE (the international real estate standards group), and other software companies in the Transaction Management, CRM, neighborhood information and online mapping areas also attended and contributed to these meetings.  Paul Stusiak, technical co-chair of the RETS group, attended and represented the RETS working group.

This diverse and talented group of technical leaders in the real estate industry came to a consensus that:

·         Using an open standard such as SAML 2.0 will allow the vendors to cooperate– making it more efficient to implement SSO securely.

·         There was no agreement on, or even serious consideration to, using a proprietary product to accomplish SSO.

·         No single entity or group should try to monetize SSO or control it by making it proprietary because this will create conflict and control issues and be a non-starter for many organizations and likely to slow adoption of free, open standards based SSO.  (Microsoft Passport was discussed as an example of why a controlling or proprietary approach is likely to fail.  Today, even Microsoft is backing open identity management and SSO standards as Bill Gates mentioned during his keynote address at the RSA Conference in February 2007)

·         Clareity and the vendor group should work with the NATIONAL ASSOCIATION OF REALTORS® (NAR) to incorporate support for SAML into the existing standard for real estate software vendor cooperation – the Real Estate Transaction Standard (RETS).

SSO via RETS

In November of 2006, NAR provided a grant to Clareity Security to build an open source reference implementation for SAML. An initial implementation has been demonstrated to NAR staff, and Clareity Security will be providing a complete, documented SAML standards toolkit to the industry for free inclusion into real estate software products in May 2007. Though Clareity Security is creating this software, Clareity will not own it,  but rather it will be owned by the real estate technology community as part of the RETS standard.  Again, if anyone were to own or control a method of Single Sign-On interaction, most vendors will not agree to use it – and vendor cooperation is at the heart of the success of Single Sign-On in our industry.

Unfortunately, there are two or three organizations in our industry that are attempting to monetize or establish control over Single Sign-On via use of proprietary products and portal technologies.

Those offering proprietary solutions are troubling: they may actually claim to be using open standards, but that is not the same as providing an open platform using those same standards. This is equivalent to Microsoft’s use of the XML standard in their Word product – Word is still a proprietary document format that gets in the way of collaboration with those not using the Microsoft product. Again, providing a common, open, and royalty free, vendor-independent platform via RETS is what is going to allow vendors to cooperate and allow for Single Sign-On adoption.

Those trying to control Single Sign-On using a portal are even more troubling and the issues additional to those described above are myriad:

First, the portal concept assumes that the portal manager is going to maintain identity (and possibly role) for everyone using all of the systems behind it. Imagine a state or local association, or its vendor, managing identity not just for association members, but for all of the non-members including MLS affiliates, unlicensed assistants and virtual assistants, brokerage staff, and potentially even for people in entirely separate industries that service ours – such as title and mortgage. This is a nightmare and the reason that the “federation” of identity outside of the enterprise/corporate environment is extremely difficult and is not available today in similar industries such as insurance, financial services, mortgage banking, or health care.  In fact, several identity portal attempts in those industries have failed miserably. The real estate industry will not be any simpler and presents a huge challenge because it is about as entrepreneurial, independent, and highly fragmented as you can get.  

Second, changing human behavior to go to a different site, other than the web application where people normally go to start their daily work, is difficult and inefficient, if not impossible. Agents (along with brokerage staff, mortgage, title, appraisers, attorneys and others) need and want to start their day on the system of their choice – their starting point can not be dictated as it can be in a corporate environment.  For example, one simply can’t tell a broker that if they want their multi-million dollar Intranet or back-office system to have Single Sign-On functionality, their agents, managers, and staff would need to log in first through an identity portal they don’t control.  This is a non-starter and larger brokers and franchises react violently to this type of intrusion in their business.  Likewise, most MLS executives or CRM desktop application vendors rightfully believe their system should be the starting point for their customers to originate SSO.  Clareity believes the broker, MLS executive, and software vendor are all correct and that as an industry we need to make SSO work for all these stakeholders if we want them to adopt SSO.

Third, it has been suggested that portals could be supported by advertisements (or user fees) and provide profits or revenue sharing to the portal operators. This would be another deal breaker for brokers, because channel conflict with advertisers is inevitable. For example, can Lending Tree, Bank of America, and HomeGain advertise on the “Realtor” portal or can we exclude these kind of advertisers?  But if there are no ads, then where does the revenue come from to support the portal and deliver profits to the owner/operators? User fees?  SSO that costs money can be compared to a toll road.  How could anyone seek to build a toll road if there were many free roads that take users to the same place? 

 Fourth, a centralized portal is vulnerable to a Distributed Denial of Service security attack, or may become unavailable for other technical reasons. A large portal is a tempting target, even Microsoft could not keep their Passport centralized service up enough of the time to serve its function acceptably - and the last thing anyone would want is for all the systems to be inaccessible because one system – the portal - was unavailable. The expense to create portals that “will never go down” and the associated risks are unacceptable and needless. The SAML standard will leverage the less vulnerable “web of trust” which underlies the way SSO is achieved in our industry already today.

 Computer Associates (CA) published a White Paper in January 2007 that explains the business value of SSO.  This paper made it clear that trust cannot be mandated, but rather is established by companies that want to do business together or provide a convenience for their employees or customers.  Following is an excerpt from that paper explaining why SSO and federation of a user’s identity are most likely to succeed in non-centralized fashion:

 “Given the intense focus on personal privacy and control of digital identities, the existing identity infrastructures that can be found in today’s organizations and the high-value of customer information that is often housed within them, it is virtually impossible to expect organizations to collaborate on creating and maintaining a universal, shared point of identity information.  Requiring organizations to first merge and centrally manage their user’s digital identities as a prerequisite to federating their applications for use by those users, is a non-starter.  This is one of the basic requirements driving federation standards and why the term “federation” (implying collaboration between loosely coupled sovereign organizations) is used in the first place.”

 For a free PDF copy of the White Paper from Computer Associates, visit www.ca.com (http://www3.ca.com/solutions/Collateral.aspx?CID=66744&ID=271)

 Single Sign-On done properly, through RETS with SAML extensions, may enable the creation of portals, but does not require there to be a portal. There can and should be hundreds of SSO portals, or as we prefer to call them, “entry points” or “authentication points” nationwide – as many as appropriate to the types of users participating in the Single Sign-On initiative in any market.  MLS systems already serve as de facto portals (or entry points) and many MLSs already serve as the authentication point for Association systems, public records, TMS, CRM, and broker systems, and provide SSO today.  Now, it’s simply time for the industry to do it better by adopting and standardizing SSO via RETS.

Conclusion

Clareity Consulting initiated open discussion of Single Sign-On in 2005 because our industry was inefficiently implementing SSO in a variety of ways and not providing it as securely as it should.  The industry vendors needed coordination to make SSO simple, standardized, secure, efficient and scalable.  Today, many of the industry’s leading technology providers have already agreed to cooperate around Single Sign-On, freely, through use of free and open-standards SSO (SAML) incorporated into the industry’s standard, RETS. Clareity Security will be providing a complete, documented SAML standards toolkit to the industry for free inclusion into real estate software products in May 2007. Though Clareity Security is creating this software, this is not a product and Clareity will not own it, but rather it will be owned by the entire real estate technology community. With your support, SAML standards will become a valuable extension to the RETS standard. By using RETS, the use of proprietary, divisive, issue-laden and potentially expensive products can be avoided, and SSO can be achieved as securely and efficiently as possible. Finally, SSO via RETS will help drive the widespread adoption of RETS 2.0 and everyone in the industry will benefit from greater standards adoption. 
 

The technical details about SSO and RETS are described in the Appendix that follows:

Appendix – The Technical Details about SSO and RETS

SSO in its basic form just means that a service provider (such as a RETS server) will trust authentication credentials provided using the SAML standard by an identity provider (such as another MLS, a strong authentication server, or another RETS server). For RETS to leverage the SAML SSO standard, RETS 2.0 must support SAML tokens. Please note that when we use the term ‘token’ in this document, we’re not talking about some sort of physical security token, but something else entirely, a security ticket that is part of the SAML standard. Please note that SSO is a concept within a single application (such as a web browser) - It does not necessarily mean that a user can move from a web browser authenticated to the MLS system to a separate RETS client application without re-authenticating within the context of the RETS client.

 

With that groundwork laid, consider the scenario where the MLS system has two RETS servers. One allows queries only for property data; the other server handles all other classes of data (agent, history, photos). To pull meaningful data, the RETS client must be able to talk to both. So the RETS Client (RC) starts a transaction with server A sending a SAML authentication token containing its login credentials. At a given point in time, the RC needs to get a photo to go with a listing. So it sends a request to server A asking for a SAML SSO token and Server A replies with that token. The RC then sends this SSO token to server B during the login transaction. Server B validates the SSO token by one of the available methods (message integrity / signing / server to server verification). Server B then lets the RC make its queries for photos.

 

So what in this is above and beyond the existing RETS standard? The first is when the RC asks for an SSO token from server A. Server A must be able to understand that request, it's not really a RETS request, it's a SAML request. It might be that we have to add something to the RETS 2.0 standard to spell this out. Additionally, server A must be able to generate those SSO tokens itself, or via a trusted third party. Server B must be able to recognize the SSO token and take the appropriate action to validate it, whether that is verifying the signature, or by checking with the issuing server.

 

One could also have the scenario where there is an independent identity provider (such as an MLS) could generate the SSO tokens once a successful authentication happens. So an MLS could have a RETS 2.0 interface for authentication only. The real RETS servers would just have to be able to accept and validate the SSO tokens.

 

In summary, to achieve SSO via RETS, the RETS servers will have to be able to understand SAML tokens, and the OASIS standards to a certain extent. Your support of the inclusion of SSO standards extensions to RETS, along with the SAML toolkit that NAR's CRT will be freely distributing soon, will help achieve that goal.