Configure an OpenID Relying Party in Liberty

We can configure a Liberty server to function as an OpenID Relying Party to take advantage of web single-sign-on.

Stabilized feature: The openid-2.0 feature is stabilized. We can continue to use the openid-2.0 feature in Liberty. However, consider using the openidConnectClient-1.0 feature. See Configure an OpenID Connect Client in Liberty.

We must have at least one OpenID Provider (OP) that is trusted with authenticating users. Several third-party OpenID Providers are available.

We can have users authenticated with an OpenID Provider by enabling the openid-2.0 feature in Liberty, and in addition to other optional configuration information.


Steps

  1. Add the openid-2.0 Liberty feature to server.xml.

    Add the following element declaration inside the featureManager element in server.xml:

      <feature>openid-2.0</feature>

  2. Update server.xml with the OpenID Relying Party configuration options specified by an <openId> element.

    For a description of configuration options for the <openId> element, see OpenID.

    We can either predefine an OpenID provider URL in server.xml using the providerIdentifier attribute of the <openId> element, or we can package the application with FormLogin which gives users an option to submit an OpenID provider URL to use for authentication.

    If the providerIdentifier attribute is added to server.xml, the Liberty server will automatically redirect users to the OpenID provider specified by that attribute. If the providerIdentifier attribute is not defined in server.xml, the Liberty server will first send a login form to ask the user to select or confirm an OpenID provider prior to redirecting the user to the OpenID provider.

    The following is a sample OpenID configuration that defines an OpenID provider: 

      <openId 
    id="myOpenId" 
    providerIdentifier="https://openid.acme.com/op" 
    userInfoRef="email">

  <userInfo 
      id="email" 
      alias="email" 
      uriType="http://axschema.org/contact/email" 
      count="1" 
      required="true" />

</openId>

    Add the openid-2.0 feature automatically enforces a certain minimum configuration. Consequently, there is no <openId> element required to be explicitly specified in server.xml. Without an <openId> element specified, the following configuration is implicit: 

      <openId 
    id="myOpenId" 
    userInfoRef="email">

  <userInfo 
      id="email" 
      alias="email" 
      uriType="http://axschema.org/contact/email" 
      count="1" 
      required="true" />

</openId>

    By default, the user's email address that is returned from the OpenID Provider is used for identity assertion and subject creation.

  3. Configure the server's truststore to include the signer certificates of the OpenID Providers supported.

    For information about keystores, see Enable SSL communication in Liberty.

    1. Extract the signer certificate from the OpenID Provider.

      Most major web browsers provide support for extracting or exporting certificates from websites through the browser interface.

    2. Import the OpenID Provider certificate to the server's truststore.

      For one method of importing certificates into a truststore, see the -import flag capabilities of the keytool utility found in the Java installation directory.

    3. Use the sslRef attribute of the <openId> element to point to your SSL configuration. If no sslRef attribute is specified, the default SSL configuration described in the keystore page mentioned previously will be used. Your SSL configuration must include the appropriate references to the truststore containing the imported OpenID Provider certificates.

  4. Optional: Configure the Authentication Filter.

    If the providerIdentifier attribute is configured inside the openId element in server.xml, we can configure authFilterRef to limit the requests that should be intercepted by the OpenID provider defined by the providerIdentifier attribute.


Parent topic: Authenticating users in Liberty


Related