IssoSpecs

I-Name Single Sign-On (ISSO) Specifications

1. Introduction
2. ISSO 1.x Specifications
1. Working Drafts
2. Referenced Specifications
3. Service Type XRI
3. Use Cases
1. Actors
2. Preconditions
3. Basic Use Case
4. Variants
1. Login Button
2. Auto-Login
3. No Confirmation
4. Anti-Pharming
4. Basic Design
1. I-Name Resolution and Service Endpoint URI Selection
2. SAML Assertion Exchange
5. New Requirements
1. I-Broker-to-Website Authentication
2. I-Broker-to-User Authentication
3. User-to-I-Broker Authentication
4. ISSO User Configuration Options
5. Logging/Reporting Requirements
6. Certification Requirements
7. Browser Support Documentation

1. Introduction

SAML

The goal of the ISSO specifications is to make ISSO as easy as possible not just for users but for the websites and i-brokers who support it. XDI.ORG, Identity Commons, 2idi, Blue Oxen, ooTao, AmSoft, and other members of the XDI Community are cooperating to develop these specifications so that all sites that install an ISSO plug-in and all i-brokers who offer ISSO service can interoperate seamlessly.

2. ISSO 1.x Specifications

2.1. Working Drafts

• Current Draft: ISSO Working Draft 01: issoV1.0.doc

• Previous Draft (Archival Only): ISSO Working Draft 00: ibroker_SSO.doc

Note: Working Draft 01 will be superceded with a new working draft incorporating the new features described below. Subscribe to this wiki page for updates as these specifications are completed.

2.2. Referenced Specifications

• The XRI 2.0 Committee Draft specifications currently in public review at OASIS. See the XRI TC home page for links to these specifications (including XRI Syntax 2.0, XRI Resolution 2.0, and XRI Metadata 2.0.)

• The XDI.ORG Global Services 1.0 Specifications (GSS) at http://gss.xdi.org.

• The SAML 2.0 specifications, now an OASIS Standard.

2.3. Service Type XRI

XRI 2.0 Resolution Specification

For ISSO service V1.0 the proposed service type and version is:

xri://$res*local.access/(+isso)*($v/1.0)

3. Use Cases

3.1. Actors

• User

• Website

• I-Broker

3.2. Preconditions

1. User has registered at least one i-name with an i-broker. This i-name must resolvable in the XDI.ORG Community (meaning a global i-name, e.g., "=example.name", or a community i-name, e.g., "@example.org*example.name").

2. I-Broker offers ISSO service and User is authorized to use it.

3. Website has installed an ISSO plug-in.

4. Website accepts ISSO assertions from i-brokers that are authenticated accredited members of the XDI.ORG Community (see New Requirements, below).

5. User has not authenticated with Website or with I-Broker in the current session.

3.3. Basic Use Case

1. User navigates to ISSO login at Website or tries to access a resource at the Website that requires authentication and Website responds with i-name login box.

2. User enters i-name into ISSO login box (see "Login Button" and "Auto-Login" variants below.)

3. Website resolves i-name and redirects User's browser (with SAML Authentication Request) to I-Broker who produces:

1. Personalized Authentication Challenge if User is not logged in to I-Broker or if User's I-Broker session has timed out; or

2. Authentication Confirmation if User is currently logged in to I-Broker. (See "No Confirmation" and "Anti-Pharming" variants below.)

4. I-Broker redirects User to Website (with SAML Authentication Response).

1. If success User is logged in at Website and is granted access to the requested resource.

2. If failure Website can try alternative means of authentication.

3.4. Variants

3.4.1. Login Button

Technical Notes:

1. While this affects the user experience at the Website, it has no technical effect on ISSO implementation.

2. To ensure continuity of user experience, Website should remember User's by i-number and not i-name. Ideally Website should remember User by all i-numbers provided as internal and external synonyms in user's XRID.

3. If the authentication fails, Website should prompt the user to enter a new i-name identity.

3.4.2. Auto-Login

It is proposed that to reduce complexity and user education, this feature not be supported in ISSO V1.

3.4.3. No Confirmation

3.4.4. Anti-Pharming

pharming

1. I-Broker produces a "Home Page Login Required" window that informs User that I-Broker does not recognize the current machine, and for User's safety User must type in User's I-Broker home page address directly (and provides the address in large letters, but not as a link, so User is not fooled into going to a spoofed site.)

2. User types in I-Broker's home page address (or navigates from another trusted site) and logs in directly at I-Broker.

3. I-Broker sets session cookie to recognize User.

4. ISSO use case completes (unless original request has timed out - see discussion below).

4. Basic Design

4.1. I-Name Resolution and Service Endpoint URI Selection

1. Website resolves i-name and in the response XRID selects the highest priority URI of the highest priority Service element matching the Service Type XRI for ISSO service (defined above). This is the Service Endpoint (SEP) URI for that User at that User's i-broker.

2. If the SAML request at that SEP URI fails, and there are other equal or lower priority SEP URIs in the same Service element, the Website SHOULD try those in order of priority.

3. If alls SEP URIs in the highest priority ISSO Service element fail, and there are other equal or lower priority ISSO Service elements in the XRID, the Website SHOULD try those in order of priority repeating the previous step for each ISSO Service element.

4.2. SAML Assertion Exchange

1. Website uses the SAML Post/Post profile to send a SAML authentication request to the SEP. It expects an SAML authentication response in return. All interactions in this exchange are governed by the SAML 2.0 protocol.

Aman, please note any exceptions here.

5. New Requirements

5.1. I-Broker-to-Website Authentication

• Websites MUST be able to obtain a verified public key of for each I-Broker participating in the ISSO network in order to verify the SAML authentication responses received from I-Broker.

• Website MUST need to be able to prove that I-Broker is an accredited member of the XDI.ORG Community in good standing. (This requirement is still under discussion, however the key justification is that the overall security of an ISSO network is only as strong as its weakest link. If a User is allowed to choose an I-Broker outside the XDI.ORG network, for whom the accrediation, security, and privacy practices are unknown, and Websites are asked to accept authentication assertions from those sites, Websites are reducing the strength of their own security to the strength of the weakest link in the network.)

Proposed design that meets only the verified public key requirement:

• Website uses an algorithm to request the public key by appending "/(+public.key)" to the SEU and doing an HTTPS GET.

Proposed design that meets both the verified public key and verified XDI.ORG community standing requirement:

• In the XRID, extend the ISSO Service element to include a NetworkAuthority child element. The value of this element would be an XRI whose value is the Community I-Number for the authoritative I-Broker (either directly in the XDI.ORG ! registry, or delegated from this registry).

• Website resolves the Community I-Number via the XDI.ORG ! registry. If the Community I-Number does not resolve, at the XDI.ORG level or a subcommunity level, the I-Broker is no longer in good standing.

• The XRID received in response would contain a Service element with a Type subelement with the value:

xri://$res*local.access/(+public.key)*(+isso)

The Service element of this type MUST contain an URI element with an HTTPS URI value.

• Website does a HTTPS GET to this URI to request the current public key.

Note: additional detail needed here about public key expiration policy.

5.2. I-Broker-to-User Authentication

Proposed design (based on that used by the Verified by Visa and MasterCard SecureCard programs):

• Users MUST enter a personalized i-broker Challenge Phrase at the time of ISSO configuration (called the "Personalized Greeting" in the MasterCard SecureCard program.)

• XDI.ORG MUST specify the screen size and elements for the I-Broker Authentication Challenge.

• The Challenge Phrase MUST ONLY be presented only when the User’s ISSO cookie is recognized by the i-broker’s ISSO service during the Authentication Challenge process.

• Users MUST be instructed to NEVER enter their i-broker password during ISSO unless they see this Challenge Phrase OR they have independently navigated to their i-broker's home page (by typing it into a browser, choosing it from their Favorites list, or following a link from a trusted site.)

• If User attempts ISSO from a new machine or public machine on which the I-Broker cookie has not been set, the I-Broker MUST respond with a "Home Page Login Required" window that does NOT allow the user to login directly, but instructs them to navigate independently to their i-brokers home page.

• I-Broker places User's XRI together with the SAML Authentication Request in a "login queue" for a specified period (probably 5 minutes). If User makes another login request in this time via the I-Broker's home page HTTPS login window, I-Broker completes the ISSO process using the original Authentication Request. (If the original request times out, User will have to return to Website manually and repeat the process, now being logged in at I-Broker.)

5.3. User-to-I-Broker Authentication

• To help prevent dictionary attacks, XDI.ORG MUST specify a minimum password strength required of all ISSO accounts in the XDI.ORG network.

• To help prevent account theft, XDI.ORG MUST specify the permitted password recovery options.

Aman, please suggest what you believe are the easiest and most secure options.

5.4. ISSO User Configuration Options

• Secure Personalized Greeting. User MUST enter the Personalized Authentication Challenge that enables I-Broker-to-User authentication.

• ISSO Session Timeout Period. User MUST be able to set the global ISSO session timeout period. This value MUST NOT be greater than the I-Broker's own policy for a maximum session timeout period. In turn this value MUST NOT be greater than the XDI.ORG-specified maximum session timeout period (which XDI.ORG MUST specify).

• Always Show Confirmation Window User MUST be able to click a checkbox to turn off I-Broker confirmation of ISSO login if User is already logged in (see "No Confirmation" variant above.)

5.5. Logging/Reporting Requirements

• XDI.ORG MUST specify if there are any universal logging/reporting requirements.

5.6. Certification Requirements

• XDI.ORG MUST specify the requirements for i-broker ISSO implementations to be certified.

5.7. Browser Support Documentation

• XDI.ORG MUST specify the browsers/browser levels required for ISSO V1.

Please report errors to the Webmaster

Immutable page (last edited 2005-07-13 14:12:03 by DrummondReed)

Or try one of these actions: AttachFile, DeletePage, LikePages, LocalSiteMap, SpellCheck