Internet Draft Y. Y. Goland Document: draft-goland-sso-human-00.txt Openwave Expires: May 2002 November 2001 Zero Install Single Sign On Solution for a HTTP Browser Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines how to enable a federated single sign on (SSO) environment across HTTP using existing HTTP/1.0 compliant clients that support 303 redirects. The goal of the system is to enable a user to authenticate to multiple websites using a single identity. Further, the mechanism must work without requiring the user to upgrade their existing web client. Goland 1 Zero Install Single Sign On Solution November 2001 for a HTTP Browser Table of Contents Status of this Memo...................................................1 Abstract..............................................................1 1. Overview.........................................................4 2. Conventions used in this document................................4 3. Glossary.........................................................5 4. Protocol Flow Overview...........................................5 4.1. Requirements.................................................5 4.2. Implementation...............................................6 4.3. Explanation.................................................10 4.3.1 Why put the burden on IPs/AAs instead of SPs?............10 4.3.2 Why the V shape?.........................................10 4.3.3 Isn't this whole system just a man in the middle attack waiting to happen?...............................................11 4.3.4 Where are the cookies?...................................12 4.3.5 Won't this system fail to work if the client's initial request was a POST?..............................................12 5. User IDs........................................................13 5.1. Requirements................................................13 5.2. Implementation..............................................13 5.3. Explanation.................................................13 5.3.1 Why a URI for a User ID?.................................13 5.3.2 How do User IDs get generated? Who owns a principal's User ID? 13 6. Discovering an IP's AA..........................................14 6.1. Requirements................................................14 6.2. Implementation..............................................14 6.3. Explanation.................................................15 6.3.1 What's a fixed path?.....................................15 6.3.2 Why do IPs have DNS names instead of full URLs?..........15 6.3.3 Why all the SHOULDs?.....................................16 6.3.4 What about user names? E-mail addresses? Telephone numbers? Etc. Why don't we use them to identify IPs?......................16 6.3.5 What about SRV records? Why only U?......................16 7. Forming the request for authentication..........................16 7.1. Requirements................................................16 7.2. Implementation..............................................16 7.2.1 Examples.................................................17 7.3. Explanation.................................................18 7.3.1 How will the SP match responses to their requests? Aren't there standards for this?........................................18 7.3.2 Why are the SP and IP elements required?.................19 7.3.3 If we have User IDs why do we have to deal with User Names? 19 8. Securing and sending the request for authentication.............19 8.1. Requirements................................................19 8.2. Implementation..............................................19 8.3. Explanation.................................................20 9. Decoding and responding to the authentication request...........20 9.1. Requirements................................................20 9.2. Implementation..............................................20 9.2.1 Examples.................................................22 Goland 2 Zero Install Single Sign On Solution November 2001 for a HTTP Browser 9.3. Explanation.................................................23 9.3.1 Why aren't the mappings between user names and user IDs required to be clearly identified in the response?...............23 9.3.2 Is the logoff URL enough? Don't we need to specify names and such to make usable UI?..........................................24 10. Use Case Scenarios.............................................24 10.1. First Visit................................................24 10.2. Second Visit...............................................27 10.3. A new SP...................................................27 10.4. Third Visit................................................27 11. XML Schema.....................................................28 12. Security Considerations........................................29 13. IANA Considerations............................................29 14. References.....................................................29 15. Author's Address...............................................29 Goland 3 Zero Install Single Sign On Solution November 2001 for a HTTP Browser 1. Overview This specification is the first entry in what is expected to be a four part series: draft-goland-sso-human-00.txt draft-goland-sso-proc-00.txt draft-goland-sso-oldwap-00.txt draft-goland-sso-moveip-00.txt The first draft focuses on creating a SSO system where the client is a human using a HTTP compliant browser. The specification only requires that the browser support 303 redirects and can handle URLs of around 4 KB in length. No assumptions are made about the media handling capabilities of the browser. The second draft focuses on creating a SSO system where the client is a program that is able to act without the direct intervention of humans. For example, a device that needs to log itself on in order to report status or a proxy acting on behalf of a client. The third draft focuses on creating a SSO system where the client is one of the first generation WAP clients. These clients have limitations that PC based clients and subsequent WAP clients do not have. Rather than requiring everyone to adopt the more complex message flow this requires, it was felt prudent to separately specify how to deal with these clients. The fourth draft provides protocols to enable one IP to move identity information to another IP. This protocol is used when a principal either wants to switch IPs or wishes to enable multiple IPs to authenticate the same identity. This draft will also specify how clients can create accounts with IPs, including providing their user ID. A note on the structure of the drafts: Each section of each draft is separated into three parts. Requirements - What do we need to do? Implementation - How do we do it? Explanation - Why did we do it that way? Once the draft is sufficiently mature the requirements sections will be cut out and put into their own draft. The implementation sections will remain as the actual 'standard'. The explanation sections are usually gathered together and published somewhere on-line so developers and those working to extend the standard can understand the decisions that led to the standard's design. 2. Conventions used in this document Goland 4 Zero Install Single Sign On Solution November 2001 for a HTTP Browser The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 3. Glossary Identity - [Ed. Note: Identity seems a little like pornography, I can't define it but I know it when I see it.] Principal - The principal is the entity that wishes to be authenticated. There are two types of principals, human and programmatic. This specification only deals with human principals. Client - The client is the web browser used by the principal. Service Provider (SP) - The service provider is a network entity that provides services to principals. Identity Provider (IP) - A service provider whose creates identities. Authentication Authority (AA) - A service provider that authenticates identities on behalf of IPs. The separation of the IP and the AA is made mostly to enable this specification to conform to the common usage of the term AA as given in sources like SAML. 4. Protocol Flow Overview 4.1. Requirements The system MUST function on existing HTTP web browsers that support 303 redirects. The system MUST assume the existence of multiple independent and unrelated IPs. The system MUST assume that SPs may only be willing to accept identities from a subset of all available IPs. The system MUST assume that IPs may only be willing to allow their identities to be used by a subset of all available SPs. The system MUST assume that principals will have multiple identities. The system MUST assume that a principal may have multiple identities with a single IP. The system MUST assume that a principal may have multiple identities with multiple IPs. The system MUST assume that the principal may have a single identity that the AAs for multiple IPs can authenticate. Goland 5 Zero Install Single Sign On Solution November 2001 for a HTTP Browser The system MUST NOT make any assumptions regarding relationships between IPs, AAs and SPs, for example, a SP could also be it's own IP and AA. The system MUST assume that authentication can only occur through the services of an AA. The system MUST assume that multiple IPs may use the services of the same AA. The system MUST assume that a single IP may use the services of multiple AAs. The system MUST assume that AAs act on behalf of IPs and so all authentication information is associated with IPs not AAs. The system MUST assume that the AAs can respond to any authentication challenges on behalf of the IP. The system MUST NOT require clients to have any capabilities beyond HTTP compliance and support for 303 redirects. Clients MUST NOT be required to install any additional software in order to implement this system. Note that SP and IPs MAY choose to include additional requirements such as support for HTTP Cookies, the ability to display HTML, WML, etc. The system SHOULD be made as easy as possible for SPs to implement, even if this means putting additional complexity on IP/AAs. 4.2. Implementation Today when a user (herein called a principal) uses their web browser (herein called a client) to go to a website (herein called a service provider) to buy something or perform any other action which requires some level of security the principal is required to authenticate themselves. The typical experience is that the service provider will send a HTML form over TLS or use basic or digest authentication to get a name and password from the principal. Every service provider the principal visits has it's own authentication database and requires a different name and password from the principal. Requiring principals to maintain stacks of names and passwords is not good from either a security perspective (the principal tends to write the names and passwords down) or from a user experience perspective. What is desired is the ability for a principal to authenticate himself or herself once and then be able to travel to any service provider and have that service provider recognize the principal's authentication. Providing this experience requires the introduction of two additional entities besides the principal, client and service provider. They are the identity provider and the authentication authority. Goland 6 Zero Install Single Sign On Solution November 2001 for a HTTP Browser Identity providers are in the business of providing identities. At their simplest an identity provider just maintains a database of user names, user IDs and passwords. The authentication authority is the actual service, usually but not necessarily, owned by the identity provider. This is the actual web server that handles authenticating the user. The authentication authority is the one who sends out the HTML Form over TLS or makes the basic or digest challenge to authenticate the user. The user experience in this system is that first a principal goes to an identity provider to get an identity. The identity provider will create three values - a user name, a user ID and a password. The user name is a human friendly name that's easy to type in and remember. For example, principal@ip.example.com. The user ID is a URI that is globally unique, for example, a UUID URI. The user ID is the principal's "real" name. That is, user names always map to user IDs. Whenever a service provider wants to track a principal they are required to use the user ID not the user name to do it. Both user IDs and user names are provided because user IDs tend to be long ugly complex expressions that no human could ever remember. The reason for using the user ID is to enable portability. Imagine that the principal doesn't like their identity provider and wants to move to another one. This is a similar experience to changing credit card providers. You can't take your credit card number with you so changing providers means getting a new number. This in turn means contacting everyone who you have given the old number to and getting them to change to the new number. This is an awful experience. To prevent it we use User IDs. That way if a principal wants to change their identity provider they take their User ID with them. Once the principal has a user ID with an identity provider the principal can begin to use that ID. When the principal navigates their client to a service provider the service provider has no way of knowing which identity provider the principal is using. Without that information the service provider has no idea how to actually authenticate the principal. Therefore the principal must tell the service provider who the principal's identity provider is. This requires the identity provider have an easily memorable name that a service provider can translate into a network address. This system already exists and is called DNS. Therefore identity providers are required to have DNS names. Having principals typing in DNS names is not the world's greatest user experience, it is only intended as a minimum guarantee of interoperability. There are other avenues available to service providers to find out the principal's identity provider that are more user friendly. For example, if the service provider only accepts identities from a relatively small group of identity providers (this is like taking American Express but not Visa) then the service provider can just list the identity providers it accepts and let the principal click on the right one. Alternatively the Goland 7 Zero Install Single Sign On Solution November 2001 for a HTTP Browser service provider can accept a user name from the principal that the service provider knows how to translate into a network address. For example, if the principal's user name is an e-mail address then the service provider can pull out the DNS name from the e-mail. If the principal's user name is a phone number then the service provider can use ENUM to translate it into a network address, etc. Once the service provider knows which identity provider the principal is using the service provider still needs to know which authentication authority the identity provider is using. See below for more details on how NAPTR DNS records are used to solve that problem. The actual authentication experience uses the following message pattern. Please refer to section 10 for more detailed message flow examples. Client SP AA | | | |1.HTTP GET Request| | -------------------> | |2.HTML Form asking for IP's Name <------------------- | |3.HTML Form response with IP's Name -------------------> | |4.303 to AA for Auth | <------------------- | |5.HTTP GET | | -------------------------> |6.HTML Form or basic/digest to get Auth Info <------------------------- |7.HTML Form or basic/digest response -------------------------> |8.303 to SP | | <------------------------- |9.HTTP GET | | -------------------> | |10.Return Page | | <------------------- | The actual communication pattern looks like a V: AA SP \ / \ / \ / 5,6,7,8 \ / 1,2,3,4,9,10 \ / \ / \ / \ / Client Goland 8 Zero Install Single Sign On Solution November 2001 for a HTTP Browser The AA and SP never directly communicate. All communication is through the client. Because the SP and AA do not directly communicate the only way to pass information between them is to encode information into the URL that the client is redirected to. This means that clients and their associated infrastructure (e.g. proxies, firewalls, etc.) need to handle URLs of a fairly large size. Experience indicates that 4 Kilobytes is the maximum URL size that is widely supported on the Internet. Steps 1 & 2 - The client asks for a page (GET/POST) that the principal has not been authenticated to access. The SP responds with a HTML form or similar UI asking for the principal's IP's DNS name. Depending on the actual UI the SP may ask the principal to choose an IP from a list, type in the IP's DNS name or provide a user name that is DNS resolvable, such as a telephone number or e-mail address. Using a DNS NAPTR record lookup the SP can translate the IP's DNS name into a HTTP URL pointing at the IP's AA(s). See section 6 for more details on the use of NAPTR. Steps 3 & 4 - The SP will create a SOAP request asking the AA to authenticate the principal. The SP will encrypt the request, URL encode it and glue it on the end of the AA's URL after the "?" character. The SP will then redirect the client to that address. Please see section 8 for details on how requests are encrypted, signed, etc. Steps 5 & 6 - The AA will pull the end off the URL, decode it and decrypt it. Assuming the request is authenticated the AA will ask the principal, using HTML forms, basic/digest, etc. to provide authentication information. Steps 7 & 8 - In it's request the SP included the URL that the AA should redirect the client to in order to deliver the AA's response. Assuming the principal successfully authenticates the AA will create a SOAP response indicating that the principal was successfully authenticated. The response will be encrypted and URL encoded and glued to the end of the URL the SP supplied in it's request after a "?". The AA will then redirect the client to that URL. The AA is also likely to put a cookie on the client establishing an authentication session between the client, principal and AA. Steps 9 & 10 - The SP will pull the end off the URL, decode it and decrypt it. Seeing that the principal/client has been authenticated the SP will return the requested page. The SP is also likely to stick a cookie on the client beginning the SP authentication session. In reading through this specification certain communities will become worried that they don't see references to their particular needs. For example, this specification refers to the use of HTML forms but not to WML forms or this specification refers to basic/digest but not to various biometric or smart card HTTP Goland 9 Zero Install Single Sign On Solution November 2001 for a HTTP Browser extensions. HTTP's negotiation mechanisms enable HTTP clients and servers to determine, at run time, what capabilities the other has and respond accordingly. Therefore all these extensions can be safely used with this specification. 4.3. Explanation 4.3.1 Why put the burden on IPs/AAs instead of SPs? The burden is placed on the IPs and AAs because they are expected to be run by professional organizations dedicated to the management and security of user information. SPs, on the other hand, are business, home user's systems, etc. that just want to leverage authentication. As such it is expected that the IPs and AAs are in a significantly better position to handle increased complexity related to the functionality of this system than the average SP is. 4.3.2 Why the V shape? Two communication patterns seemed to meet the needs of the zero install solution. The first was the V pattern described above with the SP and AA on the top and the client on the bottom. Another pattern is the triangle. The message flow in a triangle pattern would look like: Client SP AA | | | |1.HTTP Request | | -------------------> | |2.Request for IP's Name | <------------------- | |3.Supply IP's Name| | -------------------> | |4.303 to AA URL + Short ID + SP's Address (< 128 bytes) <------------------- | |5.HTTP GET | | -------------------------> |6.Request Auth Info | <------------------------- |7.Provide Auth Info | -------------------------> | |8.Confirm to SP that principal is OK | <------ | |9.Send required HTTP response | ------> |10.303 to SP | | <------------------------- |11.HTTP GET | | -------------------> | |12.Return Page | | <------------------- | Goland 10 Zero Install Single Sign On Solution November 2001 for a HTTP Browser The previous forms a triangle pattern because every member of the system communicated with every other member. Advantages to the triangle pattern: 1) Rather than trying to shove XML into URLs we can use real XML inside of nice roomy HTTP request/response bodies. 2) Because the SP and AA communicate directly they can use authentication/encryption technologies that are not available when you use URLs as your 'transport'. For example, TLS and IPSEC. 3) We enable clients and/or infrastructures that cannot handle large URLs to participate in the authentication system. The URLs used in this system only need to contain short session IDs that help the SP and AA make sure they are talking about the same client/principal. Disadvantages of the triangle pattern: 1) The system isn't very stable. Somewhere between step 7 and 12 the AA must tell the SP that the principal/client is authenticated. This means that at some point the client will have an outstanding request that cannot be answered by the SP until it gets confirmation from the AA. Given the vagaries of Internet connectivity this can result in some pretty nasty user experiences. It's especially bad because a badly implemented AA can make a well-implemented SP look bad. 2) It's slower. Rather than 5 network round trips this system requires 6. That extra round trip, averaged over the millions of logons (we hope) a day makes a big difference. In the end there isn't a slam-dunk reason to choose one over the other. Upon weighing all the possible factors the V pattern seems simpler to implement for all involved and it requires less round trips. So over all, simpler and faster would seem better. 4.3.3 Isn't this whole system just a man in the middle attack waiting to happen? Yes. For a system like this to be secure against man in the middle attacks every player has to fully authenticate themselves to every other player. The problem with this system is that the client never directly authenticates itself to the SP. Even if both legs of the V are run over TLS there is still no good way to get around a man in the middle attack. In the end security is like insurance. The amount of insurance you buy is supposed to offset the amount of risk you are unwilling to take upon yourself. Security works the same way. For some applications the cost of new clients (insurance) outweighs the risk. So those applications can reasonably make use of this system. Goland 11 Zero Install Single Sign On Solution November 2001 for a HTTP Browser Those for whom the risk is too great should look at draft-goland- sso-proc-00.txt that doesn't suffer from the man in the middle attacks. 4.3.4 Where are the cookies? While HTTP cookies are referred to in this specification they are never part of the standardized authentication mechanism. What cookies, if any, to use on a client is an issue between the SP and the client and the IP and the client. From an interoperability standpoint there is no need to specify anything about the usage of cookies. In fact, it is possible to implement the system without cookies. One can use TLS and/or one can encode the information that would have gone into cookies into URLs instead. Either way, the actual state management mechanism between the client and SP/IP isn't something this specification needs to address in order to achieve interoperability. 4.3.5 Won't this system fail to work if the client's initial request was a POST? Trying to do authentication off POSTs is usually a less than great idea. That's why most sites put in a GET page to trigger authentication before a POST page. But if a site absolutely has to do authentication off a POST then there are a couple of ways to do it. 1. Take the POST data submitted in step 1 and hide it as invisible fields in the HTTP Form returned in step 2. 2. In step 3 the invisible fields with the POST data will be returned with the principal's response to the request for their IP. Take the POST data and put it into the context field in the SOAP request that gets sent back in step 4. 3. In step 9 the client will return with the SOAP response that will contain the context element that will contain the POST field data. The response in step 10 can then be the response that would have been returned had the client already been authenticated back in step 1. A variation on the previous strategy, especially if there is a lot of POST data and one is going to make the redirect URL too large, is to record the POST data in a local DB and just send around a pointer to that DB location in the context. An alternative strategy is to return the form page in step 10 that the user originally saw in step 1 and make them enter all the data again. Goland 12 Zero Install Single Sign On Solution November 2001 for a HTTP Browser 5. User IDs 5.1. Requirements User IDs MUST be portable between IPs and usable across multiple IPs. User IDS MUST be unique across all principals for all time. 5.2. Implementation The term User ID is used for historical reasons even though the term Principal ID would be more accurate. A User ID is defined by this specification as a URI [2]. The URI that is used MUST be globally unique and assignable to one and only one principal. Note that a principal could actually be a group principal, but that is a subject beyond the scope of this paper. There is no requirement that the User ID URI be resolvable. 5.3. Explanation 5.3.1 Why a URI for a User ID? For user IDs to be transportable between IPs (or usable across IPs) the IDs must be globally unique. We could have just grabbed a single namespace, such as UUIDs and declared that to be the namespace from which user IDs must be taken. But there didn't seem to be any inherent interoperability boost by so doing. Rather, using the URI namespace, which is robustly extensible by multiple sources, seems a better solution. So long as a particular URI scheme meets the uniqueness requirements then it can be used. 5.3.2 How do User IDs get generated? Who owns a principal's User ID? User Names, the friendly names like jo@ip.example.com or even simple strings like "Jo" are owned by the identity provider. If a principal changes their IP then they loose their user name. This is why user IDs are so important and why SPs are required to track principals using user IDs and not user names. When a user moves IP they can (hopefully) take their user ID with them and that way when they go back to a SP they have visited before and authenticate with the new IP the SP will see that the user ID is identical to the one they have seen before and realize its the same principal. User IDs are likely to come from lots of different places and have lots of different policies attached. Trying to presuppose usage didn't seem very productive. For example, a company can be reasonably expected to own all the user IDs that it's employees use in the conduct of business on behalf of the company. On the other hand, consumers will probably want to own their own IDs. In the end Goland 13 Zero Install Single Sign On Solution November 2001 for a HTTP Browser the generation and ownership of IDs is a matter between principals and their IP. I suspect this will turn out like the DNS registration situation. Some DNS registrars claim that all DNS names they register really belong to them and that they simply 'lease' the names to the people who register. Other DNS registrars say that the name belongs to the people who register and they simply provide resolution services. In the end people are free to choose either type of company. 6. Discovering an IP's AA 6.1. Requirements IPs MUST be identifiable by principals using easily memorized names. An IP's AA MUST be discoverable in a manner controlled by the IP and without requiring the use of fixed paths. 6.2. Implementation To authenticate a principal the SP has to know which IP the principal is using. Once the principal is know then the SP has to find out which AA the principal wants the SP to use. Principals are expected to be able to either directly or indirectly name their IPs. The Internet already provides a standard solution for naming, DNS. As such, SPs SHOULD allow principals to identify their IP using DNS resolvable names. A SP is free to use other means, such as a list of known IPs. A SP SHOULD enable a principal to identify their IP using a straight DNS name. For example, if a principal's IP has the DNS name ip.example.com then the SP should let the user just type in that DNS address. SPs SHOULD accept HTTP URLs as well as straight DNS names and be able to remove the DNS portion of the name. For example, if the principal typed in http://ip.example.com/ the SP is encouraged to handle this gracefully. The SP should also be aware of the potential inappropriate use of the www prefix on an IP name and be ready to remove it. So, if the user typed in http://www.ip.example.com then the IP should try both ip.example.com and www.ip.example.com in the DNS resolution process defined below. The SP MAY accept other DNS resolvable names such as e-mail address or phone numbers. But in general the use of these names is discouraged as they force the principal to identify himself or herself to the SP. How the SP gets the IP's DNS name from the principal is a matter to be negotiated directly between the SP and the principal's client. It is expected that standard mechanisms such as HTML forms will be used. Goland 14 Zero Install Single Sign On Solution November 2001 for a HTTP Browser Once the SP has the IP's DNS name the SP needs to determine which AA the IP wishes to use. This requires performing a lookup into a database into which the IP's DNS address is the key and the output is the HTTP URL of the AA to redirect the user to. Such a lookup mechanism already exists in the form of the DNS NAPTR [3] record type. The IP's DNS name is to be used as the initial domain lookup value in DNS. For our purposes the string to be compared against is also the IP's DNS name. The goal of the NAPTR lookup is to find a NAPTR record advertising the HTTP protocol with the ZISSO resolution service. The end value calculated from the terminal HTTP+ZISSO NAPTR record MUST return a HTTP/HTTPS URL that points to the AA to be used in the next step of the authentication process. [Ed. Note: Need to check if it's o.k. to return a HTTPS URL when the protocol type of the NAPTR record is HTTP.] 6.3. Explanation 6.3.1 What's a fixed path? The phrase fixed path refers to the strongly discouraged practice of enable resource discovery by reserving a path in the HTTP URL path. For example, robots.txt files are always found at http://somedomain.com/robots.txt. Reserving paths like this are nice because once you know the domain name you can directly go to the appropriate location. So, for example, if you know the IP's name is ip.example.com then you can go to http://ip.example.com/zisso/aa or some equally magical path and get to the AA. In practice this type of solution proves problematic. It just seems to always break or prove too limited. Companies will have policies that say things like "You can only control paths inside of your division". So if the guys running the AA are at http://ip.example.com/aadivision then their AA path has to have that URL as it's parent. It also makes load balancing a complete nightmare as everyone runs to exactly the same URL. 6.3.2 Why do IPs have DNS names instead of full URLs? In the previous section we only required that users specify an IP's DNS name rather than providing a full path. This is unfortunate because it means that anyone who wants to be an IP has to own their own domain name. This isn't a giant hurdle but why put up any hurdles if you don't have to? In this case the decision was made to require IPs to be identified by their DNS name in order to simplify matters for principals. We needed a way to identify IPs that would be easy to remember and that means it needed to be short. DNS names were the shortest open standard naming mechanism available. Goland 15 Zero Install Single Sign On Solution November 2001 for a HTTP Browser 6.3.3 Why all the SHOULDs? The reason to use a SHOULD when there are good reasons to break a rule. For example, we specify that SPs SHOULD accept DNS names as IP names. But if the SP is in a walled garden with IPs that always use phone numbers, for example, then the SP has a good reason to break the rule. 6.3.4 What about user names? E-mail addresses? Telephone numbers? Etc. Why don't we use them to identify IPs? An SP can use any value it wants to identify an IP. Our goal here is to just provide the minimum needed for interoperability. So, for example, if a SP uses a group of IPs that share a single user name database then the SP can just ask the user to give their user name and do a lookup in the database. Telephone numbers also work well to identify IPs. One would take the phone number, apply ENUM but look for the HTTP+ZISSO service. E-mail addresses are easy, just pull out the DNS name. Etc. 6.3.5 What about SRV records? Why only U? SRV records do not allow for the user of paths, which means that all HTTP URLs derived from the SRV record would have to be of the form http://dnsname/. There is no place to put a URI path in a SRV record. This seems to restrictive so rather than go and explain how to use S records it just seemed simpler to ban them. 7. Forming the request for authentication 7.1. Requirements The authentication request MUST NOT invent YARPCF (Yet Another RPC Format). The authentication request MUST NOT require that the SP know any information about the principal. The authentication request MUST allow the SP to specify where the client is to be redirected in order to deliver the AA's response. 7.2. Implementation Now that the SP knows the AA's address it is possible to create a request for the AA to authenticate the principal. The request is expressed using a SOAP body inside of a SOAP [4] envelope. XML Element Name: Lookup Goland 16 Zero Install Single Sign On Solution November 2001 for a HTTP Browser Children: sp, ip, username (0, unbounded), userid (1, unbounded), return (1,unbounded), context (0) Explanation: The Lookup element specifies that this is a request from a SP to an AA asking that the specified principal be authenticated. XML Element Name: sp Explanation: The sp element provides the DNS name for the SP making the request. [Ed. Note: We should probably allow multiple SP names to be listed. Although this would probably mean making the return XML element a child of SP.] XML Element Name: ip Explanation: The ip element provides the DNS name for the IP making the request. [Ed. Note: There really isn't a good reason not to allow SPs and IPs to be referred to by URLs in these elements. We just need a standard way of referring to a DNS name (how about a DNS url?). Need to update the syntax to allow this.] XML Element Name: username and userid Explanation: The SP can include a list of usernames and user ids in the request. If included then the authentication request can only succeed if the principal can be authenticated by the AA as being one of the usernames and/or userids. There is no way to request that the AA authenticate the principal as being more than one of the usernames/user IDs. XML Element Name: return Explanation: The return XML element specifies what URL the client is to be redirected to in order to return the AA's response to the Lookup request. If multiple return XML elements are provided then the AA may choose to use any of them. The AA MAY assume that the elements are listed in priority order. XML Element Name: context Explanation: The context XML element is used to record data that the SP will use to re-establish context upon receiving the AA's response. The AA MUST return the contents of the context element unchanged in the response to the request. 7.2.1 Examples Below is an example of a request to authenticate a principal: shoestore.com Goland 17 Zero Install Single Sign On Solution November 2001 for a HTTP Browser myip.com principal UUID:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 http://www.shoestore.com/zisso foo:bar/blah/ick This is some context information In this request the SP, identified as shoestore.com, asks the AA to authenticate the principal as either being the principal known by the username "principal" and/or as being the principal known by the listed user ID. Shoestore asks that when authentication is complete the AA redirect the principal's client to http://www.shoestore.com/zisso. The SP also asks the content of the context element be returned, verbatim, in the AA's response. The previous example is a maximal example using all the elements that are defined below for use in a request. An example using the fewest elements possible would look like: shoestore.com myip.com http://www.shoestore.com/zisso In this example the SP doesn't know any of the principal's user names or user IDs so the username and userid elements aren't included. The SP has also chosen to glue context information onto the end of their return URL so a context element isn't included either. 7.3. Explanation 7.3.1 How will the SP match responses to their requests? Aren't there standards for this? The obvious answer is through either the context element or the return URL that can have context data buried in it. But in general it is true that a number of groups have and/or are standardizing mechanisms to associate SOAP requests and responses in asynchronous environments such as ours. The ones I have seen bring in a lot of extra baggage that didn't seem appropriate for us because they are really targeted at business process workflow systems. Goland 18 Zero Install Single Sign On Solution November 2001 for a HTTP Browser 7.3.2 Why are the SP and IP elements required? In many environments, especially ones using digital signatures, providing SP and IP values in the content is redundant at best. But in other environments, such as one in which TLS is used on both legs of the V explicitly specifying the SP and IP elements are critical. Rather than trying to confuse things by providing complex rules for when to include the elements and when not to it seemed easier to just always require them. 7.3.3 If we have User IDs why do we have to deal with User Names? It isn't very difficult to imagine a SP having a principal's user name and wanting to authenticate them based on that name. 8. Securing and sending the request for authentication 8.1. Requirements It MUST be possible for the authentication request to be encrypted, signed, etc. 8.2. Implementation In order to secure the authentication request for transport the SP and AA need to agree on what security mechanisms to use. A SP and AA are always free to negotiate a mutually acceptable authentication mechanism out of band. For example, the SP and AA may already have agreed on a secret key or a set of public keys each would use to encrypt requests and responses. [Ed. Note: Not being a security guru I shall not even attempt to specify this section. The key issue is how to enable a SP and AA to dynamically negotiate what type of security to use for the request. This requires agreeing on things like public key versus secret key, checking credentials and agreeing on the actual format to use to encrypt the key. I think, at a minimum, we should provide some sort of standard format that can be used to carry secret key encrypted contents. We could perhaps beat XMLDSIG into serving this role although it's probably too fat to fit onto a URL. We could always go minimalist and having a format like http://ip.example.com/auth?zisso:sid='sp.example.com';.] Once the authentication request has been formed and secured it MUST be URL Encoded as specified in section 2 of [2]. The AA's URL MUST then have the "?" character appended to the end of it and the URL Encoded request appended after that. The SP MUST then respond to the client's request with a 303 HTTP response code and include the previously created URL in the location header. Goland 19 Zero Install Single Sign On Solution November 2001 for a HTTP Browser 8.3. Explanation 9. Decoding and responding to the authentication request 9.1. Requirements The AA's response to the authentication request MUST include a user ID and be able to provide information regarding when the AA's authentication session with the principal/client is expected to end. 9.2. Implementation The AA will receive authentication requests at the URL the IP listed in the NAPTR lookup. The requests will be secured using the previously discussed means. The AA will need to remove the authentication request from the end of the Request-URI sent by the client, URL decode it and then remove and verify the security. For example, if the authentication request is signed then AA would need to verify the correctness of the signature. Assuming the authentication request is authenticate and appropriate then the AA will respond to the client's request with a form or similar mechanism to retrieve the client's credentials. The actual mechanism used is negotiated between the client and the AA and is out of scope for this specification. The AA places the response to a SP request inside of a LookupResponse XML element inside of a SOAP body inside of a SOAP envelope. XML Element Name: LookupResponse Children: context (0), (Success | SPSecurityFailure | RequestRefused | SyntaxError | NoMatches | PrincipalAuthFailed) XML Element Name: context Explanation: If a context XML element was included in the request then the AA MUST return it, unchanged, in the response. XML Element Name: SPSecurityFailure Explanation: The security that the SP used to wrap the request failed. It is expected that this element is unlikely to ever be used outside of a test environment. After all, responding to a security failure can, in itself, cause a denial of service attack. In addition, depending on the actual security used on the request, the AA may have no idea where to redirect the client to in order to deliver the failure notice. XML Element Name: RequestRefused Explanation: The AA refuses to work with the SP for non-technical reasons. For example, the SP may not have an appropriate legal agreement with the IP the AA is representing. XML Element Name: SyntaxError Goland 20 Zero Install Single Sign On Solution November 2001 for a HTTP Browser Explanation: The SP's request did not properly follow the schema. [Ed. Note: Probably should use the SOAP fault codes for this one.] XML Element Name: PrincipalAuthFailed Explanation: The AA was not able to authenticate the principal or was unable to authenticate the principal as any of the user names or ids listed in the request (if there were any). XML Element Name: Success Children: sp, ip, username (0, unbounded), userid (1, unbounded), aasessionlength, logoff (0,unbounded), Explanation: The AA was able to authenticate the principal. XML Element Names: sp & ip Explanation: Same as given in the section of the SP's requests. XML Element Name: username Explanation: There is no requirement that the AA provide the SP with a username for the principal. However, if, for whatever reason, the AA wishes to provide such a name then the AA may list as many names as desired. If multiple user names are listed then this means that the principal has been authenticated as being associated with all those user names. XML Element Name: userid Explanation: AAs MUST provide a userid for an authenticate user and SPs MUST use the userid when tracking the user. XML Element Name: aasessionlength Explanation: Specifies the time and date when the principal's session with the AA will expire. This is meant as a hint to the SP regarding how long it should keep it's own session with the principal before requiring a re-authentication. SPs are free to continue their session with the principal beyond the AA session expiration. For example, if all the communication between the SP and the client has been over a properly authenticated connection (say TLS) then it is reasonable for the SP to continue it's session with the principal even if the AA's session has expired. XML Element Name: logoff Explanation: When a user logs out of their SP session it is considered polite if the SP also offers the user the opportunity to logoff from their AA session. To enable this behavior the logoff element provides a URL that the client can go to in order to logoff. The SP can then use that URL in it's own UI. The mere provision of the URL provides no special power as it is expected that performing a HTTP GET on the URL will result in a form explicitly asking the user if they wish to logoff. By providing the logoff URL to the SP the AA makes it easier for the SP to provide UI that leads to the AA's logoff screen. The AA can return multiple logoff values and they are to be treated as being in priority order. Goland 21 Zero Install Single Sign On Solution November 2001 for a HTTP Browser If an authentication request includes multiple usernames and/or ids then the AA must have been able to authenticate the principal as matching at least one of these usernames or ids for a success to be returned. It is possible that a principal may actually have been successfully authenticated as matching several of the listed names or ids. The AA is under no obligation to reveal this to the SP. The only obligation the AA has is: 1) If the principal matched against a user name and nothing else in the original request then the AA MUST return, at a minimum, the principal name that was matched against in the response along with a user ID. 2) If the principal matched against a user ID and nothing else in the original request then the AA MUST return, at a minimum, the user ID that was matched against. 3) If the principal matched against multiple user names and IDs then the AA MUST return at least one value from the list of matched names and IDs. Note that none of these requirements in any way hinders the AA from returning additional usernames and user IDs in the response in order to make the SP aware of multiple identities the principal is associated with. Also note that SPs cannot assume anything about the relationship between user names and user IDs listed in a response. That is, imagine a principal has the user name UNA that matches to the user IDs UIA and UIB. The principal also has the user names UNB and UNC that match to the user IDs UIC. If the AA returns UNA, UNB, UNC, UIA, UIB and UIC in the response then the SP has no idea how to match the user names to the user IDs. The best the SP can do is to know that the principal has all these usernames and user IDs and to choose a user ID to track the principal with. 9.2.1 Examples In section 7.2.1 two requests were made. The follow example is a response to the first request where the AA refuses to work with the SP for unstated, non-technical reasons. This is some context information Goland 22 Zero Install Single Sign On Solution November 2001 for a HTTP Browser Had the AA refused the second request listed in section 7.2.1 then the response would only have differed in the absence of the context XML element. Had the first request succeeded then the response may have looked something like: This is some context information shoestore.com myip.com principal http://www.myip.com/users/principal 2002-05-31T13:20:00.000- 05:00 http://www.myip.com/logoff It so happens that the principal successfully authenticated both as the username and the user ID that was listed in the original request but the AA choose to only acknowledge the match to the user name and return a different user ID. Therefore the SP only knows about the match against the user name. The AA has instructed the SP that the AA's authentication session with the principal and client will expire on the listed date and time. The AA also specifies that the principal can logoff from the AA's authentication session by navigating to the listed HTTP URL. The SP can then integrate that URL into the SP's logoff UI. For example one could imagine that after having successfully logged off the SP the SP's final UI might include the text that contains the equivalent of "You have successfully logged off from your authentication session with your SP. If you would like to logoff from your authentication session with your AA then please click here." The link would then navigate the principal to the AA's logoff page and allow the principal to choose to logoff. 9.3. Explanation 9.3.1 Why aren't the mappings between user names and user IDs required to be clearly identified in the response? We probably should. The reason it wasn't included was due to the desire to provide the SP with the absolutely minimum required Goland 23 Zero Install Single Sign On Solution November 2001 for a HTTP Browser identifying information. Since SPs are supposed to only track principals using User IDs it seemed reasonable to make it uncomfortable for them to do anything else. 9.3.2 Is the logoff URL enough? Don't we need to specify names and such to make usable UI? The implementation text includes sample language for use with logoff, it says "You have successfully logged off from your authentication session with your SP. If you would like to logoff from your authentication session with your AA then please click here." Of course it is inconceivable that such awful, obtuse, jargon ridden language would ever be used in a real world UI. The real world UI would want to say something like "Thank you for having visited ShoeStore.Com. If you would like to logoff from MYIP.com the please click here." Only 80% of most users should get confused by this language that is better than the 99.9999% of users who would get confused by the first language. But the second proposed text requires knowing the IP's name (just using their DNS address isn't likely to work well) and probably displaying their logo and other niceties. Trying to come up with a standard to handle declaring names, logos, negotiating formats, figuring our if you can just use frames, maybe image tags, etc. in the V1 time frame just seemed silly. So it seemed reason to throw in the logoff URL to cause some thought and perhaps even remove it before we finalize V1. 10. Use Case Scenarios 10.1. First Visit Principal wishes to use a SP and IP for the first time. We assume that the SP and IP have an existing relationship and have already decided on how to handle matters such as encrypting the requests and responses. In this scenario the principal is a human. The principal and client are shown separately so as to illustrate how many times the human principal has to interact with the system. Goland 24 Zero Install Single Sign On Solution November 2001 for a HTTP Browser Principal Client SP AA IP DNS | | | | | | |1.Go to SP| | | | | -----------> | | | | | |2.GET on SP addr | | | | | -------------------> | | | | |3.Request IP Addr | | | | | <------------------- | | | |4.Display Request | | | | <----------- | | | | |5.Enter IP Addr | | | | -----------> | | | | | |6.Send IP Addr | | | | | -------------------> | | | | | |7.NAPTR Lookup for AA Addr | | -----------------> | | |8.AA addr from NAPTR | | <----------------- | |9.303 to AA Addr + Data | | | | <------------------| | | | | |10.GET on AA Addr + Data| | | | -------------------------> | | | |11.Request Auth Data | | | | <------------------------- | | |12.Display Request for Auth Data | | | <----------- | | | | |13.Fill in Response | | | | -----------> | | | | | |14.Send Auth Info to AA | | | | -------------------------> | | | |15.303 to SP Addr + Data| | | | <------------------------- | | | |16.GET on SP Addr + Data | | | -------------------> | | | | |17.Welcome Authenticated Principal | | <------------------------- | | |18.Display Request Page to Principal | | <----------- | | | | 1. Go to SP - The principal asks the Client to navigate to a particular SP. 2. GET on SP Addr - The principal's request is translated into a HTTP GET request on the SP's Addr. Note that this request doesn't have to necessarily be the GET method. 3. Request IP Addr - The SP responds with UI asking the principal to identify the principal's IP. This could be done by selecting an icon, picking from a drop down, typing in the IP's DNS address, type in the principal's IP affiliated e-mail address or even providing the principal's IP affiliated phone number. Any address that translated into a DNS name will work. Goland 25 Zero Install Single Sign On Solution November 2001 for a HTTP Browser 4. Display Request - The client displays the SP's request (probably a HTML form) to the principal. 5. Enter IP Addr - The principal responds by typing, clicking, selecting, etc. their IP. 6. Send IP Addr - The principal's response, probably a standard HTML form submit, is sent to the SP. 7. The SP performs a NAPTR lookup on the IP's DNS name for the SSO service. 8. The NAPTR resolution process finishes and the SP gets back the IP's AA address. NOTE: Both 7 and 8 are unnecessary where the SP already knows the IP's AA either due to previous lookups or due to some out of band mechanism. 9. The SP sends a 303 redirect to the client. The URL to be redirected to consists of the IP's AA address followed by a "?" followed by an encrypted SOAP request asking the AA (on behalf of the IP) to authenticate the user. 10. The client performs a HTTP GET on the redirected URL. 11. The AA asks the principal for authentication information. This could be through a HTML Form over TLS, a digest/basic challenge, etc. 12. The client presents the AA's request to the principal. 13. The principal fills in the information, which could be a name and password, a token based ID, biometric, etc. In our case it's just a HTML form asking for a name and password. 14. The client sends the authentication information, in this case a HTML form result, to the AA. 15. The AA confirms that the principal is who they claim to be and sends a HTTP redirect to the client sending them back to the SP. The redirected URL contains the SP's address (taken from the original SOAP request) followed by a "?" followed by an encrypted SOAP response. The response states that the user is who they claim to be and provides a 'log off' URL that if navigated to will remove all authentication cookies from the client that were put there by the AA. The redirect also probably contains a cookie header setting a cookie on the client specifying that the client has been authenticated for a particular principal. 16. The client performs a GET on the redirected URL. 17. The SP decrypts and checks the signature on the SOAP response confirming it's validity. Seeing that the principal is authenticated the SP returns a welcome page. The SP also probably sets a cookie on Goland 26 Zero Install Single Sign On Solution November 2001 for a HTTP Browser the client specifying the authenticated principal associated with that client. 18. The requested page is displayed to the principal. 10.2. Second Visit The authenticated client returns to the SP for another visit. The authentication session is still active. Principal Client SP AA IP DNS | | | | | | |1.Go to SP| | | | | -----------> | | | | | |2.GET on SP addr | | | | | -------------------> | | | | |3.Return Requested Page | | | | <------------------- | | | |4.Display page to Principal | | | | <----------- | | | | In this scenario the GET request in step 2 contained a cookie set by the SP on the client specifying that the authenticated principal associated with the client. As the cookie had not expired the client was allowed immediate access. 10.3. A new SP While the principal's authentication session with the AA is still active the principal visits a new SP that the principal has not been to before. The message flow is identical to the one given in section 10.1 with the exception of steps 11 through 14. Since the AA's authentication session with the principal/client is still active the AA will skip steps 11 through 14 and go directly to step 15. Therefore the principal need never see any UI from the AA. 10.4. Third Visit Some time later the authenticate client returns again to the SP. But now the authentication session with the SP and the IP has expired. The exact nature of the subsequent message flow depends on several factors. The numbers for the steps given below are taken from section 10.1. Steps 3 - 6: It is tempting to skip steps 3 through 6 since the SP already knows the IP that the principal used when previously authenticating. If skipping these steps then the principal would be redirected to the AA for authentication (note that steps 7 through 10 may still be necessary). What if the principal has decided to change their IP? In that case the authentication dialog from the old Goland 27 Zero Install Single Sign On Solution November 2001 for a HTTP Browser IP's AA won't be very useful. As such SPs that want to skip steps 3 to 6 when re-authenticating a principal are urged to use frames or a similar mechanism so that at least part of the screen is still controlled by the SP and will let the principal indicate that they do not wish to be authenticated by their previous IP's AA. Alternative the SP can choose not to skip 3 through 6 and do a full re-login. Steps 7 - 8: If the TTL for the cached NAPTR responses haven't expired then these steps can be skipped. 11. XML Schema The XML elements used inside of the SOAP body XML element are defined using the syntax provided by the W3C's XML Schema [5]. Goland 28 Zero Install Single Sign On Solution November 2001 for a HTTP Browser [Ed. Note: Need to define regex for DNS] 12. Security Considerations [Ed. Note: I will put aside six or seven weeks to write this section.] 13. IANA Considerations [Ed. Note: The ZISSO names are just placeholders for the NAPTR resolution service and the URI protocol type.] 14. References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998 3 Mealling, M., "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000 4 Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H. F., Thatte, S., Winer, D., "Simple Object Access Protocol (SOAP) 1.1", W3C Note, May 2000 5 Thompson, H. S., Beech, D., Maloney, M., Mendelsohn, N., "XML Schema Part 1: Structures", W3C Recommendation, May 2001 15. Author's Address Yaron Y. Goland Openwave Email: yaron.goland@openwave.com Goland 29