+

Search Tips   |   Advanced Search

Defining an OAuth service provider

An OAuth service provider is a named set of configuration options for OAuth. The id or name of the provider is specified in the URL of inbound requests to the authorization and token endpoints. The set of configuration options for that provider is used when the request is handled. This process allows one server with one endpoint servlet to effectively provide multiple OAuth configurations. For example, the https://my.company.com:8021/oauth2/endpoint/photoShare/authorize URL is handled using the set of OAuth configuration options defined for the OAuth provider named photoShare. The https://my.company.com:8021/oauth2/endpoint/calendarAuthz/authorize URL is handled using the set of OAuth configuration options defined for the OAuth provider named calendarAuthz.

An OAuth service provider is defined with the oauthProvider element in server.xml. We can define an OAuth service provider by editing server.xml or using the WebSphere Application Server Development Tools for Liberty Profile. This task describes how to define a minimal OAuth configuration.

  1. Add the oauth-2.0 and ssl-1.0 features. OAuth is a secure protocol so SSL is required. On the Liberty profile, supply a keystore password for SSL using the keyStore element. There is no default keystore password.
    <featureManager>
      <feature>oauth-2.0</feature>
      <feature>ssl-1.0</feature>
    </featureManager>

  2. Set up the role mapping for the OAuth web application using the oauth-roles element. OAuth is an HTTP-based protocol and a web application is supplied to handle the authorization and token endpoints. The web application is built in and is started automatically when we specify the oauth-2.0 feature. However, we must map the authenticated role to one or more users, groups, or special subjects. Another role, clientManager, is supplied for managing client configuration, but it is not necessary to map that role for OAuth authorization to function.
    <oauth-roles>
      <authenticated>
        <user>testuser</user>
      </authenticated>
    </oauth-roles>

  3. Define one or more providers with the oauthProvider element. The provider must have at least one client defined. Clients can be defined locally with the localStore and client elements. Clients can also be defined in a relational database with the databaseStore element.
    <oauthProvider id="SampleProvider" filter="request-url%=ssodemo">
      <localStore>
        <client name="client01" secret="{xor}LDo8LTor"
                displayname="Test client number 1"
                redirect="http://localhost:1234/oauthclient/redirect.jsp"
                enabled="true" />
      </localStore>
    </oauthProvider>

  4. Define a user registry, either an LDAP registry by specifying the ldapRegistry-3.0 feature and the ldapRegistry configuration element, or a basic registry by specifying the basicRegistry configuration element.
    <basicRegistry id="basic" realm="BasicRealm">
      <user name="testuser" password="testuserpwd" />
    </basicRegistry>

  5. Set the allowFailOverToBasicAuth web application security property to true.


Results

We have defined a minimal OAuth configuration.


Example

The following example shows a sample server.xml file that defines a simple OAuth provider with one client:
<server>

  <featureManager>
    <feature>oauth-2.0</feature>
    <feature>ssl-1.0</feature>
  </featureManager>

  <keyStore password="keyspass" />

  <oauth-roles>
    <authenticated>
      <user>testuser</user>
    </authenticated>
  </oauth-roles>

  <oauthProvider id="SampleProvider" filter="request-url%=ssodemo">
    <localStore>
      <client name="client01" secret="{xor}LDo8LTor"
              displayname="Test client number 1"
              redirect="http://localhost:1234/oauthclient/redirect.jsp"
              enabled="true" />
    </localStore>
  </oauthProvider>

  <webAppSecurity allowFailOverToBasicAuth="true" />

  <basicRegistry id="basic" realm="BasicRealm">
    <user name="testuser" password="testuserpwd" />
  </basicRegistry>

</server>


Parent topic: OAuth 2.0 services

Concepts:

  • OAuth full profile provider configuration equivalents

    Tasks:

    Configure an OpenID Connect Provider

    Configure an OpenID Connect Provider to use the RSA-SHA256 algorithm for signing of ID tokens