Org.eclipse.higgins.idas.cp.openid

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} This is an experimental project so it is currently located in the nursery: https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/nursery/ along with its sister ".test" project.

OpenID Context Provider

The motivation for creating this Context Provider was to experiment with OpenID integration and interoperability. There was not a customer demand, nor are there currently customers using this CP in production. Before placing this CP in production please review the Limitations section below.

How it Works

The Context Provider acts as both the Consumer (Relying Party) and the browser and attempts to authenticate to an OpenID provider, retrieving any requested attributes.

All of these steps can happen when the IdAs consumer initiates authentication via Context.open or requests an attribute that has not been previously retrieved.

• Acting as the OpenID Consumer (Relying Party) in the OpenID Protocol Flow
  • Accept the authentication materials
  • Using the OpenID found in the authentication materials do Provider discovery, including delegation
  • Do OpenID Consumer Association with the OpenID Provider
• At this stage normally a Consumer would redirect the browser to the Provider, instead the CP acts as the clients browser
  • Send the query containing all required information to the OpenID Provider, the OpenID Provider may require autentication or may redirect back to the Consumer
  • Use the authentication materials to authenticate
  • If the OpenID Provider wants to know about the trust relationship we currently recommend one time trust.
  • Parse the response and pull out any attributes

Gory Details

The OpenID CP uses openid4java libraries to act as the Relying Party. When talking to the Identity Provider it uses the Jericho html parsing library to parse the forms, then uses Rhino javascript to evaluate the form and fill in inputs.

OpenID is currently an authentication protocol which might return attributes, if SREG and/or Attribute Exchange are supported by the OP. This means if additional attributes are needed the CP must reauthenticate.

Reference Deployment

Currently this CP is deployed as part of the reference application found on [bandit-project.org] try it out! Steps:

1. Setup your machine for InfoCards, for help see the Pamela Project's HowTo Guide
2. Obtain an OpenID (please only use openids from the Compatible Providers section below.
   1. If you do not have an OpenID you may obtain one from any of these sites
   2. If you do not want to create an OpenID, you may use an anonymous (no password required) OpenID provided by [1]
3. To create a card backed by an OpenID, place the OpenID in the user id field in this form, input a card name, then select the OpenID button. You do not need to provide the password.
4. Save the card into your preferred identity selector.
5. Go to an InfoCard enabled site which doesn't require much by way of trust (for example Pamela's Test Blog) and login.

Compatible OpenID Providers

Because authentication methods are not a part of the OpenID specifications, and are often form based this context provider may require configuration changes before it interoperates with a given OpenID Provider.

The following OpenID providers are part of the unit tests of this project, using the configuration from the unit tests you can try the following providers: OpenSSO

Provider	Supported	Comments
jkg	yes	free anonymous OpenIDs, no authentication or trust, Returns hardcoded values in SREG fields
regged.de	yes	Doesn't appear to support SREG
MyLid	yes	Doesn't appear to support SREG
OpenSSO	no	uses client side javascript to rewrite the document, we can't parse and fill in the authentication form correctly.
videntity	yes	Doesn't appear to support SREG
protectnetwork
getOpenID	yes	Doesn't appear to support SREG
Verisign	yes	supports SREG, seems to be very robust and full featured

Adding Providers

Any assistance in testing and adding the configuration needed for other OpenID providers would be appreciated.

Configuration

NOTE: The OpenID Context Provider configuration XML file format was designed to be used to configure any number and type of Context Providers. Other Higgins Context Providers contributed by Novell currently use this same format. Work is currently underway which may change or eliminate this method of CP configuration.

The OpenID Context Provider is configured through an XML file whose format is specified by the following XML schema:

Configuration XML Schema

Limitations

IdAS

This Context Provider is not a full featured CP, it implements only enough of the IdAS interfaces to allow reading of Digital Subjects and their associated attributes. There is no support for updates, metadata on any object, or schema.

The IdAS implementation is sufficient for the Higgins Token Service to create Entity objects and transform those into Digital Identity objects which can be returned as various token types, Allowing OpenIDs to participate in ws-federation.

Security

When this CP is deployed as part of a Token Service it is possible that instead of the Evil RP problem, we have the potential for an Evil STS. The Evil STS would be deployed by a malicious person for the purposes of man in the middle attacks, logging credential information. Please note this is only possible if the user accepts InfoCards from the Evil STS.

OpenID

• Attribute exchange is implemented but not tested
• Because the CP acts as a browser it must have all of the Trust roots and certs a browser would have. Often the Java keystore doesn't have all of the required certs resulting in SSL handshake errors.
• OpenID providers which require client side scripting for their authentication forms to work can't be evaluated and parsed correctly by this CP

Future Plans

• Continue to add support for additional OpenID Providers
• Support basic authentication
• Expand unit tests to include providers which support Attribute Exchange
• Visit and cleanup all Todo statements in code
• Finish Javadoc
• Remove configuration from the context ref (part of general Higgins IdAS todo list.)
• Add more decision points
• Auditing

Lessons Learned

• Many OpenID providers are still very basic with no support for 2.x features or SREG, many are good only for authentication.
• Many OpenID providers don't don't have any protection against brute force attacks, allowing countless missed passwords without any delays or auditing of failures.
  • This CP might simplify the amount of code an attackers must write to attempt brute force attacks
  • Deployments of this CP might be used to attack OpenID providers, partially masking from the provider the true source of the attack.
• As has been said many times OpenID is not a Trust System.
• Higgins needs profile descriptions so that IdAS Context Providers can declare meet the profile of this type of deployment, without having to be full featured. (I know it's an open source project and I should contribute to those profile descriptions.)

See Also

• OpenID
• OpenID specifications
• OpenID RP Attack
• openid4java
• Higgins Home
• IdAS
• Components