Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Cloud Selector 1.1
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
The Higgins Cloud Selector is a web application which allows users to access and use their i-cards via the OpenID protocol, without the need for any locally installed selector. This can be useful on platforms where selector software is not available, as well as in scenarios in which the requirement for users to install extra software is considered to be unacceptable.
Contents
Introduction
The Higgins Cloud Selector functions as an OpenID IdP for use by standard OpenID RPs. It supports the following types of OpenID requests:
- OpenID Authentication 1.1 and 2.0: This simply authenticates the user, without using i-cards
- OpenID Attribute Exchange 1.0 Fetch: This allows the RP to request an i-card from the user
- OpenID Attribute Exchange 1.0 Store: This allows the RP to offer a new i-card to the user
The Higgins Cloud Selector uses the I-Card Service for retrieving and managing the user's i-cards.
The OpenID identifier (which can be a URI or an XRI) consists of a preconfigured base part, and a dynamic part which directly maps to the user's account name in the Higgins I-Card Service.
For example, if the user's Higgins account name is "joe", then they could use the following OpenIDs:
- my.server.com/joe - URI form
- =myserver*joe - XRI form
Security/Privacy Considerations
The main downside of this approach is reduced privacy, since the i-cards of a user become highly correlatable via the OpenID identifier that is being authenticated.
Another problem may be OpenID-related security issues (e.g. phishing) that do not occur with locally installed i-card selector solutions.
The Higgins Cloud Selector does not reveal the existence/non-existence of user accounts in the I-Card Service to unauthorized users. It initially answers requests to any identifier and only checks its existence at the point when the user enters their password.
End-User Perspective
End-users of the Higgins Cloud Selector do not need to install anything. From their perspective, everything happens in the browser. However, they need to know the following:
- Their account name and password in the Higgins I-Card Service.
- How to form an OpenID identifier from their account name.
E.g. if their account name is joe, they need to know that they can use the OpenID identifiers http://my.server.com/joe or =myserver*joe.
Other than that, all the end-user needs to do is select an i-card and (if the card is password protected) enter the i-card's password, just like they would in an installed selector.
Example OpenID relying party:
The Higgins Cloud Selector authenticating the user:
The Higgins Cloud Selector asking the user to select an i-card:
Try it
- Go to http://higgins.eclipse.org/cloud-selector-test/. This is an OpenID test relying party.
- Enter =higgins*ms43 as the OpenID identifier. Note that ms43 is the name of an account in a Higgins I-Card Service.
- Click on the Mode REQUEST 1 tab.
- Click on the radio button.
- Click Go.
- You will see an OpenID debugging page. Click Continue.
- You will be asked for the password of the I-Card Service associated with the OpenID. Type azigo and click Authenticate.
- You see some cards from the I-Card Service. Select one and click Send this Card. If the card requires a password, select a different one.
- You will again see an OpenID debugging page. Click Continue.
- Now you are back at the OpenID test relying party. It has received some values from the card you selected.
Deployer Perspective
The Higgins Cloud Selector is a Java web application which can be deployed in a standard servlet container. It connects to the Higgins Server (I-Card Service) for accessing the users' i-cards.
Configuration
The main configuration file is WEB-INF/application.properties.:
- rpps: This is the endpoint of the Higgins I-Card Service which is used to authenticate users as well as access their i-cards.
- server-url: This is the absolute URL to the Higgins Cloud Selector. You have to set this according to your environment.
- xri-providerid: The i-number of the parent XRI for your community i-names. This is only needed to support XRI OpenIDs. E.g. if you want to offer community i-names in the form =myserver*joe, then the value of this parameter must be the i-number of =myserver.
Other files:
- *.jsp: These files can be customized for appearance.
- top.txt and bottom.txt: These files are included by the *.jsp files and can also be customized for appearance.
- discovery-uri-html.txt: This file is served when an OpenID RP performs discovery on a URI OpenID. It can be customized for appearance.
- discovery-uri-xrd.txt: This is an XRD file served for discovery on URI OpenIDs. This should not be changed.
- discovery-xri-xrd.txt: This is an XRD file served for discovery on XRI OpenIDs. This should not be changed.
URI OpenID Identifiers
Users can use the following URI identifiers at OpenID relying parties:
(server-url) / (Higgins account name)
E.g. if the Higgins Cloud Selector is deployed at http://my.server.com, and your Higgins account name is joe, then you can use the following URI OpenID identifier:
XRI OpenID Identifiers
Users can use the following XRI identifiers at OpenID relying parties:
(parent-xri) * (Higgins account name)
E.g. if the parent XRI is =myserver, and your Higgins account name is joe, then you can use the following XRI OpenID identifier:
=myserver*joe
This assumes that the parent XRI has been properly configured to delegate XRI authority resolution to the Higgins Cloud Selector, e.g. with a service endpoint like this:
<Service priority="10"> <ProviderID>xri://=!89F9.2C84.ACEA.F2F0</ProviderID> <Type select="true">xri://$res*auth*($v*2.0)</Type> <MediaType select="false">application/xrds+xml</MediaType> <URI append="none" priority="2">http://my.server.com/</URI> </Service>
Developer Perspective
Architecture
The Higgins Cloud Selector is a standalone web application that relies on a Higgins server's I-Card Service API.
See I-Card Service.
Building
The Higgins Cloud Selector projects are:
- app/org.eclipse.higgins.proxy.web (the Higgins Cloud Selector itself)
- app/org.eclipse.higgins.proxy.test (an example OpenID RP)
These project can be checked out from the Eclipse repository at the following SVN URIs:
Also you should download third-party dependency package openid4java-nodeps-0.9.5-SNAPSHOT.jar that is not approved by eclipse from http://code.google.com/p/openid4java/
Put openid4java-nodeps-0.9.5-SNAPSHOT.jar package to org.eclipse.higgins.proxy.web/lib folder and run ANT with "buildwar.xml [web]" parameter.
Developing an OpenID RP
The Higgins Cloud Selector should work with any standard OpenID RP. For a list of tools for developing such RPs, see http://openidenabled.com/.
Authenticating the user's identifier
Authenticating users does not involve i-cards. The OpenID RP initiates a standard OpenID Authentication request. The Higgins Cloud Selector then simply asks the user for their Higgins account password and returns an OpenID Authentication response to the RP.
Requesting an i-card
In order to a ask the user to select an i-card, the OpenID RP has to use the Attribute Exchange (AX) or Simple Registration (SREG) extension. Several methods are supported:
Method 1: AX attribute identifiers are claim URIs
In this method the OpenID RP issues an AX "Fetch" request. The AX attribute identifiers which the RP requests are simply the claim URIs from the user's i-cards. E.g. if the RP would like to request the required claims "first name" and "e-mail address", as well as the optional claim "last name", then the OpenID AX parameters could look like this:
openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.mode=fetch_request openid.ax.type.emailaddress=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress openid.ax.type.givenname=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname openid.ax.type.surname=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname openid.ax.required=emailaddress,givenname openid.ax.if_available=surname
Method 2a: Well-known AX attribute identifiers are mapped to claim URIs
In this method the OpenID RP issues an AX "Fetch" request. The RP requests well-known AX attributes, and the OpenID IdP (the Cloud Selector) attempts to map them to standard claim URIs. For example, if the RP would like to request the required claims "first name" and "e-mail address", as well as the optional claim "last name", then the OpenID AX parameters could look like this:
openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.mode=fetch_request openid.ax.type.emailaddress=http://axschema.org/contact/email openid.ax.type.givenname=http://axschema.org/namePerson/first openid.ax.type.surname=http://axschema.org/namePerson/last openid.ax.required=emailaddress,givenname openid.ax.if_available=surname
For this to work, the OpenID IdP (the Cloud Selector) must have a mapping which internally translates between AX attribute identifiers and claim URIs. A simple mapping could look like this:
http://axschema.org/contact/email -> http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress http://axschema.org/namePerson/first -> http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname http://axschema.org/namePerson/last -> http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
Method 2b: Well-known SREG attribute identifiers are mapped to claim URIs
In this method the OpenID RP issues a SREG request. The RP requests well-known SREG attributes, and the OpenID IdP (the Cloud Selector) attempts to map them to standard claim URIs. For example, if the RP would like to request the required claims "first name" and "e-mail address", as well as the optional claim "last name", then the OpenID SREG parameters could look like this:
openid.ns.sreg=http://openid.net/extensions/sreg/1.1 openid.sreg.required=email,nickname openid.sreg.optional=fullname
For this to work, the OpenID IdP (the Cloud Selector) must have a mapping which internally translates between SREG attribute identifiers and claim URIs. A simple mapping could look like this:
openid.sreg.email -> http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress openid.sreg.nickname -> http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname openid.sreg.fullname -> http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
Note: The last two entries in the above example mapping are not really semantically accurate...
Method 3: Advanced IMI compatibility
In this method a special profile of AX is used in order to achieve the following two goals.
- It should be possible for RPs to use the same policy mechanism as for Selector-based IMI. E.g. with an <object> element or WS-Policy.
- It should be possible for RPs to receive a full security token from an STS instead of just the extracted attribute values.
In order to achieve both goals, the OpenID RP requests a single attribute which is intended to hold a security token from an STS. The attribute identifier for this attribute is defined to be
urn:imi-token
The RP adds to this attribute identifier a query string which holds a base64-encoded <object> element which specifies the RP's policy. For example, if the RP would like to request the required claims "first name" and "e-mail address", as well as the optional claim "last name", then the OpenID AX parameters could look like this:
openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.mode=fetch_request openid.ax.type.token=urn:imi-token?PG9iamVjdCB... openid.ax.if_available=token
Note that PG9iamVjdCB... is the base64-encoding of the following <object> element:
<object type="application/x-informationCard" name="xmlToken"> <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion" /> <param name="requiredClaims" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" /> <param name="optionalClaims" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" /> </object>
The OpenID IdP (the Cloud Selector) can then attempt to fulfill the RP's policy, and it can return a full token from an STS. It therefore behaves just like a locally installed Selector, except that OpenID is used as a transport protocol for the token.
In order to properly encrypt the token, the OpenID IdP (the Cloud Selector) needs the OpenID RP's certificate. This is obtained by performing a simple HTTP GET on the openid.return_to parameter of the OpenID request. If this parameter does not contain a https URL, the returned token will not be encrypted.
Other ideas for this method 3 are:
- Instead of an AX profile a separate OpenID extension could be defined
- Instead of passing a base64 <object> element, the RP could pass a URL. The IdP would use this URL to fetch the RP's policy as well as its certificate for encrypting the token.
- Instead of passing a base64 <object> element or a URL via a query string, the RP could pass this information via an AX "Store" operation
- Instead of an <object> element WS-Policy could be used
Offering an i-card
In order to offer the user a new i-card, the OpenID RP has to use the Attribute Exchange (AX) extension with a Store request. The request must contain a special attribute with the alias "icard" whose value must be the i-card in XML format that is being offered to the user. Example:
openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.mode=store_request openid.ax.type.icard=http://schemas.xmlsoap.org/ws/2005/05/identity openid.ax.value.icard=[here the .crd XML data]