2 Protecting Services Gatekeeper Resources with OAuth

This chapter explains how to protect Oracle Communications Services Gatekeeper resources with the Open Authorization Protocol (OAuth). It starts with information you need to understand about the OAuth technology, then explains the deployment procedure, and finally lists some examples to help you understand the process.

Managing OAuth Resources

This section describes OAuth resource management as supported by Services Gatekeeper.

Understanding Resource Mapping

You protect Service Gatekeeper communication services by mapping those communication services to OAuth resources.

In order to protect an API with OAuth, you model the API method as an OAuth resource, one API to one resource. Resource mapping involves creating a unique scopeId to represent the resource, and then mapping the scopeId to the API and method names.

You can also define additional context parameters for the resource to use as targets for custom interceptors. These parameters may or may not map directly to the API method parameters.

You can create multiple resources for a single communication service. In this case, resources are aggregated and defined as XML elements in a single XML file. The scopeId defined in this XML file is used as part of the scope submitted during an authorization grant request. Created resources need to be mapped to the resource owners (identified by subscriber tel:/sip: URIs). Resource owners then issue authorization grants to the scopeIds (resources) that they own.

See "Understanding the OAuth Resource Format" for details on the resource format and a resource example.

Understanding the Services Gatekeeper Resource Server

As an OAuth Resource Server, Services Gatekeeper manages the protected resources contained within a service provider's network and accepts and responds to third-party application requests for access to protected resources.

In Services Gatekeeper, a resource is considered to be a communication service method. Resources can have subresources, each of which is represented by a method derived from the resource. Authorization grants to a resource also apply to its subresources. For example, for a payment communication service, a resource called amountTransaction can be created for charging transactions. A subresource called checkTransactionStatus is a method used to query the status of a charging transaction.

Understanding the Services Gatekeeper Authorization Server

As an OAuth Authorization Server, Services Gatekeeper obtains a subscriber's permission for access to protected resources when an application makes a request. Services Gatekeeper issues a token to the client application, which is used to access protected resources without requiring the resource owner to provide actual credentials.

When a client application requests access to a protected resource, the Services Gatekeeper REST handler initially checks the request, ensuring that the body contains the needed authorization information. If the request is valid, Services Gatekeeper forwards the request onto the proper communication service. An OAuth interceptor verifies that the token contained in the request is valid before completing the request. Services Gatekeeper then sends a response back to the client application.

Services Gatekeeper can also act as a SAML identity manager that accepts SAML token requests and grants the corresponding SAML tokens. You can use these tokens to supply permission to use resources protected by OAuth. You also have the ability to grant access to resources with federated identities such as single sign-ons (SSOs). You create the SSOs using an identity manager such as Oracle Fusion Middleware Identity and Access Management product (which contains Oracle Identity Manager), or another identity access management product. The SSO authorizations then allow the subscriber access to all resources protected by the SSO.

Understanding the Services Gatekeeper Authentication Server

As an Authentication Server, Services Gatekeeper maintains a subscriber database used to store the owners of protected resources. OAuth 2.0 resource owners in Services Gatekeeper must be setup as subscribers in the Authentication Server first. The Authentication Server is used to authenticate subscribers, as resource owners, before initiating authorization to protected resources.

The included Authentication Server is intended for OAuth 2.0 demonstration and development purposes.

Provisioning Mapped Resources

Services Gatekeeper contains a JMX interface for uploading resource mapping files. The interface name is included in the OAuthResourceMBean MBean, which you can access using MBean browser, such as the WebLogic Administration Console, the Oracle Access Manager (OAM) interface (a part of the Oracle Fusion Middleware Identity and Access Management product), the Services Gatekeeper Platform Test Environment (PTE). You load or retrieve resources using this MBean.

For more information on the fields and methods of OAuthResourceMBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

Managing Clients

You can map a client to an existing Services Gatekeeper application instanceId. This mapping lets you use existing SLA enforcement with OAuth security. You manage application clients using the OAuthClientMBean, which is available from the OAM WebLogic interface or the PTE. You use this MBean to search for clients or return a list of them. You can also add, remove, or update clients.

For more information on the fields and methods of OAuthClientMBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

Mapping Resources to Resource Owners

You must define a resource owner for each resource that Services Gatekeeper protects. You manage resource owners using the OAuthResourceOwnerMBean. You use this MBean to add, remove, or update resource owners. For all operations, the format of a resourceScope is space separated scopeId list.

For more information on the fields and methods of OAuthResourceOwnerMBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

Authenticating Subscribers

Services Gatekeeper acts as an authentication server. You create and authenticate subscribers in the Services Gatekeeper database.

To authenticate users, Services Gatekeeper supports a component called the Subscriber Manager which provisions subscribers, authenticates them, and expands GroupURIs. You manage subscribers using the SubscriberMBean MBean.

For more information on the fields and methods of SubscriberMBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

About the MBeans Used to Provide OAuth Functionality

You administer the Services Gatekeeper OAuth server using these MBeans in domain_home/ocsg/container_services/OAuthService:

  • OAuthCommonMBean

  • OAuthClientMBean

  • OAuthresourceMBean

  • TokenManagerMBean

For more information on the fields and methods of these MBeans, see the "All Classes" section of Services Gatekeeper OAM Java API Reference. For more information about Services Gatekeeper administration, see Services Gatekeeper System Administrator's Guide.

Understanding OAuth EAR Files

The OAuth EAR files are deployed as part of the Services Gatekeeper installation.

EDRs and Alarms

The Services Gatekeeper OAuth implementation functions as an application running on the WebLogic application server host. You can configuration EDRs and alarms manually if needed. See the chapter on ”Managing and Configuring EDRs, CDRs and Alarms” in Services Gatekeeper System Administrator's Guide for more information.

Deploying and Configuring OAuth Functionality

To deploy and configure the Services Gatekeeper OAuth functionality:

  1. Confirm that the OAuth EAR files are deployed.

  2. Configure OAuth.

    See "Configuring OAuth" for more information.

  3. Create the protected resources in Services Gatekeeper.

    See "Configuring Resource Rules to Protect Resources" for more information.

  4. Configure the Authentication URL.

    See "Configuring Authentication" for more information.

  5. Configure resource rules to protect the usage of your resources.

    See "Configuring Resource Rules to Protect Resources" for more information.

  6. Create the client identifier(s) and credentials in Services Gatekeeper that will request access to protected resources.

    See "Configuring Clients to Protect Access to Resources" for more information.

See:

Configuring OAuth

To configure OAuth, use the methods of the OAuthCommonMBean MBean to update (or configure) Services Gatekeeper for use with OAuth.

For more information on the fields and methods of OAuthCommonMBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

Creating Protected Resources

Create protected resources by doing the following:

Protecting RESTful Communication Services

To enable OAuth protection for RESTful communication services (including custom communication services), you map communication services to OAuth resources. You then use the OAuthResourceMBean to upload resource mapping to Services Gatekeeper.

For more information on the fields and methods of OAuthResourceMBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

Protecting Subscription Resources

Services Gatekeeper uses operations in the OAuthResourceMBean to protect subscription resources. See ”Services Gatekeeper OAuth 2.0 Authorization and Resource Servers” in Services Gatekeeper Communication Service Reference Guide.

Configuring Authentication

In order to grant an authorization code, a resource owner must be authenticated and authorize the scope of the grant. The resource owner can be authenticated using these methods:

A resource owner controls its resources and can allow a client to access them. For each resource, one or more resource owners need to be defined using the SubscriberMBean.

Using the Default Subscriber Manager

Services Gatekeeper offers a built-in subscriber repository to authenticate subscribers. To use the default Subscriber Manager to authenticate subscribers, do the following:

  1. Create the subscribers in Services Gatekeeper using the SubscriberMBean Mbean. Use the methods of this MBean to configure and maintain subscribers. Access the SubscriberMBean MBean through the OAM Console or the PTE Tools MBean browser.

    For more information on the fields and methods of SubscriberMBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

  2. Verify that the AuthenticationURL property of OAuthCommonMbean is set to:

    https://app_server_IP:app_server_port/oauth2/auth.jsp

Using Delegated Authentication

Instead of provisioning users in the Services Gatekeeper database, you can delegate authentication to a custom authentication server.

See "Implementing a Third-Party Authentication Service" for more information.

See "Understanding the OAuth Resource Format" for details on the resource format.

Configuring Resource Rules to Protect Resources

Protecting resources with resource rules comprises the following tasks:

Creating Individual Resource Owners

Create the individual resource owners using the methods of the OAuthResourceOwnerMBean MBean. For more information on the fields and methods of this MBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

Creating a Resource Rules File Using Regular Expressions

You map resource owners to their resources using regular expressions. To do so, you create an XML rules file that defines the resource owner/resource mapping and save this file.

See resource_rule.xsd for the schema definition.

The rules file that you create maps resource owner addresses, represented by a regular expression, to a list of one or more resources. The rules file is interpreted when OAuth grants the authorization, and rules must be defined in order of priority from most specific to most general.

In the following example, owner/resource mapping rules are defined with the most specific rules at the beginning of the file, proceeding to the most general rules at the end. Placing a more specific rule, with a regular expression such as ^1390.*$, at the start of the file ensures that the expected cases are caught and correctly interpreted first. Then the rules with more general regular expressions, such as ^.*$, toward the end of the file serves as a stop gaps to catch the unexpected or rarer cases.

Example 2-1 Regular Expression Rules File

<?xml version="1.0" encoding="UTF-8"?>
<tns:addressResourceRules
xmlns:tns="http://oracle/ocsg/oauth2/management/resource_rule"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- numbers start with '1390' own the 'location' and 'payment' services  -->
<tns:rule addressPattern="^1390.*$" resources="location payment"/>
<!-- numbers start with '139' own the 'location' service  -->
<tns:rule addressPattern="^139.*$" resources="location"/>
<!-- All other resources are protected and no resource owners are defined. -->
<!-- Any request with a scope not defined in this xml file will be rejected. -->
<tns:rule addressPattern="^.*$" resources=""/>
</tns:addressResourceRules>

Uploading the Resource Rules to Services Gatekeeper

Upload the saved resource rules XML file to Services Gatekeeper using the loadResourceRuleXml method in OAuthResourceMBean MBean.

To retrieve the current rules XML file, you use the retrieveResourceRuleXml method.

For more information on the fields and methods of the OAuthResourceMBean MBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

Configuring Clients to Protect Access to Resources

Services Gatekeeper enables you to create an application client to support the authorization code grant type. A client registers with its password and the allowed redirect URI in Services Gatekeeper.

Use the fields and methods of the OAuthClientMBean MBean to configure and maintain application clients. You can access this MBean using an MBean browser, such as the OAM Console, WebLogic Administration Console, or the Platform Test Environment (PTE).

For more information on the fields and methods of the OAuthResourceMBean MBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

Configuring SAML (Optional)

This section explains how to configure Services Gatekeeper as a SAML authorization server. It is an optional step.

To configure Services Gatekeeper to use SAML federated identities follow these general steps:

  1. Configure Oauth in Services Gatekeeper. See these sections for details:

  2. Import the certifications from your identity provider using the keytool program.

    See ”Adding Certificates to the Application Tier Servers and Applications” in Services Gatekeeper System Administrator's Guide for details.

  3. Set up a trusted relationship between the requesting application and your identity provider. See your identity provider documentation for instructions.

  4. Configure your SAML application to add and remove excess tokens. To do so, use the OauthSamlMbean methods. For more information on the fields and methods of the OauthSamlMbean MBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

Protecting Resources in a Custom Communication Service

You can create a custom RESTful communication service using the Platform Development Studio (PDS) wizard and deploy the service on the Services Gatekeeper platform. This service is automatically protected by OAuth.

The service must be provisioned as an OAuth2.0 resource as described in the following steps:

  1. Deploy the service into the Services Gatekeeper server.

    For example:

    Interfacename=com.foo.DemoMethod=bar 
    
  2. Execute the loadResourceXml operation in the OAuthResourceMbean to create a resource element. For example, use the following XML:

    <resource id="foo_id " name="Demo
     Service" interfaceName=" com.foo.Demo" methodName=" bar" 
            tokenExpirePeriod="3600">        </resource>
    
  3. Execute the addResourceOwner operation in the OAuthResourceOwnerMbean with the following values (where the resource_owner_address is the TEL:/SIP: URI):

    address=${resource_owner_address}resourceScope=foo_id
    

After completing the above steps, the custom RESTful communication service can be accessed if a resource owner grants access to any application client.

Figure 2-1 illustrates the above steps.

Figure 2-1 Protecting a Custom Communication Service

Description of Figure 2-1 follows
Description of ''Figure 2-1 Protecting a Custom Communication Service''

Example: Protecting the OneAPI Payment Service with OAuth

This section explains how to protect the OneAPI Payment Service with OAuth.

Adding a Client in Services Gatekeeper

  1. Open the MBean browser in PTE or use the OAM WebLogic interface to access the addClient operation in the OAuthClient MBean at:

    Wlng, OauthServer, OauthClientMBean, addClient()

  2. Use the following parameters for the addclient operation:

    • Id: app123

    • Name: App123_name

    • Password: password

    • Description: Demo Application

    • AllowRedirectURI: https://localhost/app/redirect.php

    • AppInstanceId: domain_user

  3. Submit the parameters to add the new client.

Configuring the Authentication URL

  1. Open the MBean browser in PTE or use the OAM WebLogic interface to access the AuthenticationURL configuration setting in the OAuthCommon MBean at:

    Wlng, OauthServer, OauthCommonMBean, AuthenticationURL

  2. Use the following parameter for the AuthenticationURL field:

    AuthenticationURL: https://app_tier_host:app_tier_port/oauth2/auth.jsp

  3. Submit the parameter to set the authentication URL.

Adding One API Payment Communication Service as an OAuth resource

  1. Open the MBean browser in PTE or use the OAM to access the loadResourceXml operation in the OAuthResourceMBean at:

    Wlng, OauthServer, OauthResourceMBean, loadResourceXml()

  2. Use the following sample XML content for the FileContent parameter field:

    <?xml version="1.0" encoding="UTF-8"?>
    <resources xmlns="http://oracle/Services Gatekeeper/oauth2/management/xml"
     mlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
      <!--  OneAPI Payment  amountTransaction    -->
      <resource id="POST-/payment/acr:Authorization/transactions/amount"
     name="Charge or refund" interfaceName="oracle.Services
     Gatekeeper.parlayrest.plugin.PaymentPlugin" methodName="amountTransaction"
     tokenExpirePeriod="3600">
            <parameter name="code" description="billable item id"/>
      </resource> 
    </resources>
    
  3. Submit the parameter to add the payment service as an OAuth resource.

Adding a New Subscriber

  1. Open the MBean browser in PTE or use the OAM WebLogic interface to access the addSubscriber operation in the SubscriberMBean at:

    Wlng, SubscriberService, SubscriberMBean, addSubscriber()

  2. Use the following parameters for the addSubscriber operation:

    • Address: tel:888

    • LoginID: Jack

    • Password: password

  3. Submit the parameters to create a subscriber.

Assigning the Resource to the Subscriber to Act as Resource owner

  1. Open the MBean browser in PTE or use the OAM WebLogic interface to access the addResourceOwner operation in the OAuthResourceOwnerMBean at:

    Wlng, OauthServer, OauthResourceOwnerMBean, addResourceOwner()

  2. Use the following parameters for the addResourceOwner operation:

    • Address: tel:888

    • resourceScope: POST-/payment/acr:Authorization/transactions/amount

  3. Submit the parameters to create a subscriber.

Understanding the OAuth Resource Format

The Services Gatekeeper OAuth resource format is defined in the oauth_resource.xsd file located in the middleware_home/ocsg_6.0/applicationsoauth2_nt.ear file. To view the resource schema definition use an archive manager to expand wlng_nt_oauth2.ear.

Example 2-2 shows the contents of the oauth_resource.xsd file:

Example 2-2 oauth_resource.xsd file

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" 
  targetNamespace="http://oracle/ocsg/oauth2/management/xml"
      xmlns:tns="http://oracle/ocsg/oauth2/management/xml" 
      elementFormDefault="qualified">
      <element name="resources">
         <complexType>
            <complexContent>
               <extension base="tns:OAuthResources">
               </extension>
         </complexContent>
      </complexType>
      <unique name="resourceIdUnique">
          <selector xpath="tns:resource"/>
          <field xpath="@id"/>
      </unique>
</element>
 
<complexType name="ResourceParameter">
   <annotation>
      <documentation>
         Parameter of resource.
      </documentation>
      </annotation>
      <attribute name="name" type="string" use="required">
        <annotation>
           <documentation>
             Parameter name.
           </documentation>
        </annotation>
        </attribute>
        <attribute name="description" type="string" use="required">
          <annotation>
             <documentation>
               Parameter description.
             </documentation>
         <annotation>
       </attribute>
    </complexType>
 
 
    <complexType name="OAuthResources">
       <annotation>
         <documentation>
            All supported OAuth2.0 resources in the resource server of OCSG.
         </documentation>
       </annotation>
       <sequence>
          <element name="resource" type="tns:OAuthResource" minOccurs="0" maxOccurs="unbounded"></element>
       </sequence>
   </complexType>
 
   <complexType name="OAuthResource">
      <annotation>
         <documentation>
            Define a OAuth2.0 resource.
         </documentation>
     </annotation>
     <sequence>
       <element name="parameter" type="tns:ResourceParameter" minOccurs="0" maxOccurs="unbounded"></element>
       <element name="subResource" type="string" minOccurs="0" maxOccurs="unbounded"></element>
    </sequence>
    <attribute name="id" type="string" use="required">
      <annotation>
         <documentation>
            Resource identifier.
         </documentation>
     </annotation>
    </attribute>
   <attribute name="name" type="string" use="required">
      <annotation>
         <documentation>
            Resource name.
         </documentation>
         </annotation>
   </attribute>
   <attribute name="interfaceName" type="string" use="required">
       <annotation>
         <documentation>
            Plug-in north interface name of the resource.
         </documentation>
      </annotation>
   </attribute>
   <attribute name="methodName" type="string" use="required">
      <annotation>
      <documentation>
         Plug-in north method name of the resource.
       </documentation>
   </annotation>
   </attribute>
   <attribute name="tokenExpirePeriod" type="int" use="optional" default="3600">
      <annotation>
         <documentation>
            Token expire period by seconds.
         </documentation>
      </annotation>
   </attribute>
   </complexType>
</schema>

Table 2-1 lists the resource structure and attributes.

Table 2-1 oauth_resource.xml Resource Structure and Attributes

Attributes Type Description

id

String

Unique identifier for the resource scope (required). As part of an authorization grant, the Id (as the scopeId), is submitted as part of the scope-token parameter value.

name

String

Resource name (required). A concise description of a resource which can be used for display purposes.

interfaceName

String

Plug-in north interface name of the resource (required).

methodName

String

Plug-in north method name of the resource (required).

tokenExpirePeriod

Int

Number of seconds until a token expires (optional). If multiple resources (scopes) are granted with a single token, the earliest token expiration period will be enforced on the token. If the resource has subResources, then the earliest token expiration period configured among all resources will be used.

subResource

String

One or more resources that can exist within the scope of the resource (optional). The value of this field should be an id of another resource.

parameter

ResourceParameter

One or more parameters valid for the resource (optional). These parameter(s) are submitted as part of the OAuth authorization grant. During an authorization grant, a resource may accept several parameters, and each of the parameters can have two attributes, name and description. Parameters defined as part of the resource do not need to be directly related to the method parameters of an API.

The semantics of the parameters can be interpreted by a custom interceptor by examining the RequestContext.For example, for the following scope value:

chargeAmount?code=123

The chargeAmount is the scopeId mapped in Services Gatekeeper, the code represents the parameter name and 123 represents the parameter value.As part of communication service access (resource access), a custom interceptor can be written to interpret the OAuth token scope and RequestContext and validate the token usage against the authorization scope.


Resource Representation Example

The following is an example XML representation of the OAuth resource mapping for a OneAPI communication service:

<?xml version="1.0" encoding="UTF-8"?>
<resources xmlns="http://oracle/Services Gatekeeper/OAuth2.0 /management/xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- amountTransaction  -->
  <resource id="chargeAmount" name="Charge or refund" 
        interfaceName="oracle.Services Gatekeeper.parlayrest.plugin.PaymentPlugin" methodName="amountTransaction"
        tokenExpirePeriod="3600">
        <parameter name="code" description="billable item id"/>
        <subResource>checkTransactionStatus</subResource>
  </resource>
  
  <!-- list amount transactions -->
  <resource id="listAmount" name="List amount transactions" 
    interfaceName="oracle.Services Gatekeeper.parlayrest.plugin.PaymentPlugin" methodName="listTransaction"
    tokenExpirePeriod="3600">
        <subResource>checkTransactionStatus</subResource>
  </resource>  
    
  <!-- get amount transaction -->
  <resource id="checkTransactionStatus" name="Get amount transaction" 
    interfaceName="oracle.Services Gatekeeper.parlayrest.plugin.PaymentPlugin" methodName="checkTransactionStatus"
    tokenExpirePeriod="3600"/>
</resources> 

The following resources are defined in this example:

  • chargeAmount: a token can be obtained for this resource, but this restricts the access of the resource (OneAPI charging API) to the code specified as part of the scope parameter value.

  • listAmount

  • checkTransactionStatus

In addition, one subResource is also defined. The checkTransactionStatus subResource is defined as a subResource for the chargeAmount and listAmount resources. By defining checkTransactionStatus as a subResource, Services Gatekeeper facilitates using the same access token obtained for chargeAmount while accessing the checkTransactionStatus resource.