⁠15.13. OpenID

Warning

Technology Preview features are not fully supported under Red Hat subscription level agreements (SLAs), may not be functionally complete, and are not intended for production use. However, these features provide early access to upcoming product innovations, enabling customers to test functionality and provide feedback during the development process. As Red Hat considers making future iterations of Technology Preview features generally available, we will provide commercially reasonable efforts to resolve any reported issues that customers experience when using these features.
OpenID is a community standard for external web-based authentication. Any web application can supplement (or replace) its local authentication handling by delegating responsibility to an external OpenID server selected by the user. This benefits both user and developer — the user (who no longer needs to remember login details for multiple web applications), and the developer (who need not maintain an entire complex authentication system).
When using OpenID, the user selects an OpenID provider, and the provider assigns the user an OpenID. The ID takes the form of a URL — http://maximoburrito.myopenid.com, for example. (The http:// portion of the identifier can be omitted when logging into a site.) The web application (known as a relying party) determines which OpenID server to contact and redirects the user to the remote site for authentication. When authentication succeeds, the user is given the (cryptographically secure) token proving his identity and is redirected back to the original web application. The local web application can then assume that the user accessing the application owns the OpenID presented.
However, authentication does not imply authorization. The web application must still determine how to treat the OpenID authentication. The web application can choose to treat the user as instantly logged in and grant full access to the system, or it can attempt to map the OpenID to a local user account and prompt unregistered users to register. This is a design decision for the local application.

⁠15.13.1. Configuring OpenID

Seam uses the openid4java package, and requires four additional JARs to make use of Seam integration. These are htmlparser.jar, openid4java.jar, openxri-client.jar and openxri-syntax.jar.
OpenID processing requires the OpenIdPhaseListener, which should be added to your faces-config.xml file. The phase listener processes the callback from the OpenID provider, allowing re-entry into the local application. 
​<lifecycle> 
​  <phase-listener>
​    org.jboss.seam.security.openid.OpenIdPhaseListener
​  </phase-listener> 
​</lifecycle>
This configuration makes OpenID support available to your application. The OpenID support component, org.jboss.seam.security.openid.openid, is installed automatically if the openid4java classes are on the classpath.

⁠15.13.2. Presenting an OpenIdLogin form

To initiate an OpenID log in, present a form to the user requesting the user's OpenID. The #{openid.id} value accepts the user's OpenID and the #{openid.login} action initiates an authentication request. 
​<h:form> 
​  <h:inputText value="#{openid.id}" /> 
​  <h:commandButton action="#{openid.login}" value="OpenID Login"/> 
​</h:form>
When the user submits the login form, they are redirected to their OpenID provider. The user eventually returns to your application through the Seam pseudo-view /openid.xhtml, provided by the OpenIdPhaseListener. Your application can handle the OpenID response with a pages.xml navigation from that view, just as if the user had never left your application.

⁠15.13.3. Logging in immediately

The simplest strategy is to simply log the user in immediately. The following navigation rule shows how to handle this using the #{openid.loginImmediately()} action. 
​<page view-id="/openid.xhtml">
​  <navigation evaluate="#{openid.loginImmediately()}">
​    <rule if-outcome="true">
​      <redirect view-id="/main.xhtml">
​        <message>OpenID login successful...</message>
​      </redirect>
​    </rule>
​    <rule if-outcome="false">
​      <redirect view-id="/main.xhtml">
​        <message>OpenID login rejected...</message>
​      </redirect>
​    </rule>
​  </navigation>
​</page>
The loginImmediately() action checks whether the OpenID is valid. If it is valid, an OpenIdPrincipal is added to the identity component, and the user is marked as logged in (that is, #{identity.loggedIn} is marked true), and the loginImmediately() action returns true. If the OpenID is not validated, the method returns false, and the user re-enters the application un-authenticated. If the user's OpenID is valid, it will be accessible using the expression #{openid.validatedId} and #{openid.valid} will be true.

⁠15.13.4. Deferring log in

If you do not want the user to be immediately logged in to your application, your navigation should check the #{openid.valid} property, and redirect the user to a local registration or processing page. Here, you can ask for more information and create a local user account, or present a CAPTCHA to avoid programmatic registrations. When your process is complete, you can log the user in by calling the loginImmediately method, either through EL (as shown previously), or direct interaction with the org.jboss.seam.security.openid.OpenId component. You can also write custom code to interact with the Seam identity component to create even more customized behavior.

⁠15.13.5. Logging out

Logging out (forgetting an OpenID association) is done by calling #{openid.logout}. You can call this method directly if you are not using Seam Security. If you are using Seam Security, you should continue to use #{identity.logout} and install an event handler to capture the log out event, calling the OpenID log out method. 
​<event type="org.jboss.seam.security.loggedOut"> 
​  <action execute="#{openid.logout}" /> 
​</event>
It is important to include this, or the user will not be able to log in again in the same session.