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