Skip to main content

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.

Jump to: navigation, search

Cloud Selector 1.1

(Redirected from Cloud Selector)

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins logo 76Wx100H.jpg

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.

Introduction

OpenID AX flow

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:

Higgins-web-proxy-shot1.png

The Higgins Cloud Selector authenticating the user:

Higgins-web-proxy-shot2.png

The Higgins Cloud Selector asking the user to select an i-card:

Higgins-web-proxy-shot3.png

Try it

  1. Go to http://higgins.eclipse.org/cloud-selector-test/. This is an OpenID test relying party.
  2. Enter =higgins*ms43 as the OpenID identifier. Note that ms43 is the name of an account in a Higgins I-Card Service.
  3. Click on the Mode REQUEST 1 tab.
  4. Click on the radio button.
  5. Click Go.
  6. You will see an OpenID debugging page. Click Continue.
  7. You will be asked for the password of the I-Card Service associated with the OpenID. Type azigo and click Authenticate.
  8. 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.
  9. You will again see an OpenID debugging page. Click Continue.
  10. 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:

http://my.server.com/joe

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.

Cloud-selector-1.1.105.png

(Diagram Key)

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:

https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/app/org.eclipse.higgins.proxy.web
https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/app/org.eclipse.higgins.proxy.test

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.

  1. 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.
  2. 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]

Links

Back to the top