...

After successful OpenID authentication, the Relying Party gets a identifier string for the user. Its possible to transfer additional profile information such as email address, but this is not readily usable for authorization decisions. There's also the identity of the OP. So there are about 2.5 pieces of information available: #user

1. user id

...

1. OP id

...

1. the fact that the user is authenticated by some OP
   For JavaEE security these need to be mapped to application specific roles. This means that either there is very coarse grained security based only on the fact that the user is authenticated or on which OP they are using, or the relying party web app needs explicit knowledge of each user to map them to appropriate roles.

Geronimo support

Geronimo OpenID support uses the openid4java libraries.

OpenID Provider support

The org.apache.geronimo.plugins/openid-provider-jetty//car plugin is a simple OP app for jetty. Currently it uses a simple properties file login module for user authentication. This needs to be moved to a separate plugin so the realm can be pluggable. The app application uses form based login so it maintains a session for the authenticated user: thus for repeated requests from relying parties only the "do you want to allow authentication to this relying party" notice is necessary, not actual app login for every request.

...

• if the user is not authenticated (request.getUserPrincipal is null) then the user is redirected (through the user agent) to the (protected) authentication page. Through normal javaee Java EE security this results in requiring the user to log in before getting to the authentication page.
• if the user is already logged in the request is forwarded (through a request dispatcher) to the authentication page.
  If the user accepts the authentication request from the relying party, the openid protocol continues.

...

The OpenID provider appears to work at least minimally based on modified unit tests from the openid4java project.

Relying Party support

The OpenID protocol specifies a sequence of message exchanges between the relying party and the user agent (and thence the OP, through redirection). It is thus a good candidate for a JASPI module, substituting for the standard basic, digest, or form based message exchanges. This is being developed in the jaspi component. When complete it will allow specifying OpenID authentication just as you can now specify basic, digest, or form authentication, although not through web.xml.