5 Federated Single Sign-On Using Oracle Identity Federation

Users need to access content on different corporate Web sites. Corporate Web sites need to authenticate and authorize users who are entering from different domains that use different security products. The Oracle Identity Federation product addresses these problems.When a user tries to access a protected resource on a remote Web site, the Oracle Identity Federation product at the user's site transfers information about the user to the remote site for use in authorizing the user's request. For example:

• Users from an airline can access technical documentation in an airplane vendor's documentation database.

• Customers of a wireless company can access a bill-paying application that is outsourced from the vendor to a third-party supplier.

• Employees of an organization can access a 401(k) application through an internal HR portal that connects to the benefits provider.

Users might click a link on their own company's Web site to request access to content on a partner (Service Provider) Web site. The first time users request access, they are authenticated on their home (or Identity Provider) domain using information stored in their home site's user data repository. The user's home domain forwards the access request to the Service Provider site along with the credentials that the Service Provider site needs to authorize the request.

Oracle Access Manager can serve as the authentication engine for federated single sign-on using Oracle Identity Federation.

In addition to federated single sign-on, you can extract user attributes from the Oracle Access Manager user directory for federated authorization. This is useful when a Service Provider needs additional information to authorize users to access resources. For example, if you are a Service Provider and your authorization policies require specific user attributes that are not available on a user's request, you may need to send a request to the identity Provider for additional user attributes that are needed for authorization. In Oracle Access Manager, you configure authentication and authorization plug-ins to query the user's home site (the Identity Provider) for these attributes.

This chapter discusses the following topics:

• About Federated Single Sign-On

• About Federated Authorization

• Setting up the Federated Attribute Sharing Environment

• Configuring the Authentication Scheme for Attribute Sharing

• Configuring the Authorization Schemes and Policies for Attribute Sharing

5.1 About Federated Single Sign-On

Information about single sign-on between Oracle Access Manager and Oracle Identity Federation is provided in the Oracle Identity Federation Administrator's Guide. This guide is available from the Oracle Documentation page on the Oracle Technology Network. The URL is as follows:

http://www.oracle.com/technology/documentation

5.2 About Federated Authorization

When the Access System at a Service Provider site receives a request from a user in a federated environment, it may need to get additional information about the user from the user's Identity Provider. For example, the user may authenticate to the Service Provider using SSL with an x.509 certificate, then attempt to access a resource that is protected by the Access System using an x.509-based authentication scheme. If the user is not defined in the Service Provider's user repository, the Access System may need additional user attributes from the Identity Provider to be able to make an authorization decision.

If you have Oracle Identity Federation installed at your site, and you receive requests from other sites that have installed Oracle Identity Federation (or another product that implements the SAML Attribute Sharing Profile for x.509 Authentication-Based Systems), you can configure the Access System to perform federated authorization.

This section describes the components involved in authorization decisions based on federated requests for additional user attributes.

The following process overview describes a scenario where federated attribute sharing is used for authorization.

Process overview: Attribute sharing used for federated authorization

1. A user authenticates to your Service Provider domain using x.509 client certificate authentication.

   Client certificate authentication is required for this process.

2. The user requests a resource in your domain.

   Your domain is the Service Provider. A WebGate protects the requested resource.

3. The WebGate intercepts the request and directs it to the Access Server.

4. An attribute-sharing authentication plug-in determines that the user is not defined in the local Oracle Access Manager System.

5. An authentication step sets up the conditions for using an attribute-sharing authorization plug-in.

6. The attribute sharing authorization plug-in extracts user identity from the user's x.509 certificate and forwards it to the local instance of Oracle Identity Federation.

7. The local Oracle Identity Federation engine constructs a SAML attribute request and forwards it to the SAML service (for example, Oracle Identity Federation) at the user's home domain (the Identity Provider).

8. The SAML service at the Identity Provider extracts the user attributes from the request, verifies the user identity, and returns a response to the Service Provider instance of Oracle Identity Federation.

9. The response is forwarded to the Access Server to complete the authorization process.

Components of attribute sharing-based authorization are as follows:

• A config.xml file—A configuration file is read during Access Server start-up.

  This configuration file specifies user DN patterns and associated URLs that point to instances of Oracle Identity Federation at the Service Provider domain. The authentication and authorization plug-ins for attribute sharing use the DN patterns to determine if a user is local or remote. For remote users, the associated URLs indicate the instance of Oracle Identity Federation that should receive requests for additional information about the user.

  This file also provides authentication information that Access System sends requests to identify itself to the Oracle Identity Federation instance.

  You also configure logging and system-related settings in this file.

• An authentication plug-in for attribute sharing—This plug-in determines if a user is local, that is, if the user has an identity in the local Oracle Access Manager System.

  If the plug-in determines that the user is local, the authentication scheme associated with the plug-in creates a local Oracle Access Manager session for the user. If the plug-in determines that the user is remote, the scheme creates a placeholder session for the OblixAnonymous user.

• An authorization plug-in for attribute sharing—The attribute sharing authorization plug-in constructs a request for attributes that are required for authorizing the user. The plug-in sends the request to an instance of Oracle Identity Federation at the local domain. The configuration file that the Access Server reads at start-up time determines the URL where the request is sent.

  The Oracle Identity Federation instance at the local domain forwards a SAML request to the SAML service at the Identity Provider.

  The SAML service at the Identity Provider responds to the request, and the response is sent along the same route back to the Access System. If the Access System obtains the requested attributes, it provides access to resources and other authorization actions based on the rules configured in the authorization scheme.

Note:

This chapter only describes configuration of attribute sharing authorization in the Access System. However, reciprocal configuration must be performed on the local Oracle Identity Federation server. For more information on Oracle Identity Federation, see the Oracle Identity Federation Administrator's Guide, available from the Oracle Documentation page on the Oracle Technology Network. The URL is as follows:

http://www.oracle.com/technology/documentation

5.3 Setting up the Federated Attribute Sharing Environment

Setting up the environment includes configuring basic parameters to identify the attributes to be used in authorization, URLs for the Oracle Identity Federation, setting up secure communication channels, configuring logging, and other tasks.

The following sections provide information on these topics:

• Setting Parameters in the config.xml File

• Configuring Basic Authentication

• Configuring SSL and Client Certificate Authentication

• Configure the Session Token Cache for Federated Attribute Sharing

5.3.1 Setting Parameters in the config.xml File

The config.xml file contains settings for associating local Oracle Identity Federation instances with users's Identity Providers based on information in the user's DN entry. It also contains settings that control what information related to attribute sharing is written to a log, and other settings to control interaction with the Access System.

The config.xml file is located in the following directory:

Access_Server_install_dir/access/oblix/config/attributePlugin/ config.xml

The following is a sample config.xml file:

<Config LogLevel="audit" WaitTime="30" SizeLimit="0" MaxConnections="5"
     InitialConnections="2" Authn="cert" Username="MyAccessServer"
     Password="MyPassword" KeyPassword="MyKeyPassword" CacheTimeout="30"
     MaxCachedUsers="1000" HeaderKeyLength="128" HeaderKeyRegen="86400"
     RequestFormat="values">
   <Mapping Local="true">
       <DN>OU=Engg,O=MyCompany,L=MyCity,ST=California,C=US</DN>
   </Mapping>
   <Mapping URL="https://host1.us.company.com:8888/osfs/ar/soap">
       <DN>OU=Test,O=MyCompany,L=MyCity,ST=California,C=US</DN>
   </Mapping>
   <Mapping URL="https://host2.us.company.com:8777/osfs/ar/soap">
       <DN>C=US</DN>
       <DN>C=IN</DN>
   </Mapping>
   <Mapping URL=http://SP-HOST:SP-PORT/fed/ar/soap">
        <DN>O=Partner1,C=US</DN>
   </Mapping>
   <Mapping URL="http://SP-HOST:SP-PORT/fed/ar/soap" RequestFormat="all">
        <DN>O=Partner2,C=US</DN>
    </Mapping>   
</Config>

This file contains the following attributes:

Table 5-1 Attributes in the config.xml File

Attribute	Description
LogLevel	Controls the amount of information that is logged to AS_install_dir/oblix/logs/authz_attribute_plugin_log.txt. The following are possible values for this parameter: none—Nothing is logged except errors (the default). audit—One line is logged for each authorization request, showing the access decision, the user's certificate subject DN or local directory DN, and the HTTP operation and the local part of the requested URL. debug—Extensive information used in debugging problems.
HTTP connection parameters	The authorization plug-in uses these parameters. These parameters contain information that is sent from the Access System to the Oracle Identity Federation instance. You can configure the following HTTP connection parameters: WaitTime—Time in seconds to wait for a response. Default: 30 seconds. SizeLimit—Maximum size in bytes of HTTP messages sent and received. 0 means unlimited (the default). MaxConnections—The maximum number of concurrent HTTP connections. Default: 5. InitialConnections—Number of concurrent HTTP connections opened initially. Default: 2.
Authentication parameters	Authenticates the authorization plug-in to the Oracle Identity Federation instance. You can configure the following authentication parameters: Authn—The authentication method. The following are possible values for this parameter: none—No authentication is used. basic—Use HTTP basic authentication with user name and password (the default). cert—Use SSL client certificate authentication using key.pem, cert.pem, and KeyPassword. Username—The username for basic authentication. Password—The password for basic authentication. KeyPassword—The password for key.pem for SSL client certificate authentication.
Attribute value cache parameters	This cache is located in the authorization plug-in memory in the Access Server. You can set values for caching parameters: CacheTimeout—The time in seconds that cached attributes values are held before requiring updated values. A value of 0 disables caching. Default: 3600 seconds (1 hour). MaxCachedUsers—The maximum number of users whose attribute values can be cached. If the cache is full, entries with the oldest unexpired entries are reclaimed. Default: 1,000.
Encryption parameters	HeaderKeyLength—The length (in bits) of a key that is generated for AES encryption of the SubjectDN header. This header is passed from the authentication plug-in to the authorization plug-in. Possible values for this parameter: 128, 192, or 256. Higher values provide stronger encryption but slower performance. A value of 0 disables encryption of the header. Oracle does not recommend setting a value of 0 due to potential impersonation attacks. HeaderKeyRegen—The interval (in seconds) for regenerating the key that encrypts the SubjectDN header. The default is 86400 (one day).
Attribute query properties	The RequestFormat parameter determines what attributes and values are returned on an attribute response. This parameter overrides authorization rules. For example, if an authorization rule specifies attributes and values, the RequestFormat parameter can omit the values from a request. You can specify the RequestFormat parameter in the global CONFIG element or in a local MAPPING element in the config.xml file. For example, in the sample config.xml file shown above this table, Partner2 uses a local RequestFormat setting. The RequestFormat parameter can be configured as follows: RequestFormat="values"—This setting enables a query for information about a user to contain attribute names and values. The names and values are taken from the authorization rule expression that you configured for federated attribute sharing. With this setting, the response from the Identity Provider only returns user attributes and values that match those in the query. This is the default setting. This setting minimizes the memory used for cached attribute values because the request contains only the values neededed for authorization. This setting results in more frequent attribute requests. RequestFormat="names"—This setting permits a query to contain attribute names, but not the values that you configured in the authorization rule expression that you configured for federated attribute sharing. The response from the Identity Provider returns the user's values for the named attributes, as long as the Identity Provider's Responder policies permit access to the values. This setting uses more cache memory than the "values" setting, but less than the "all" setting. This setting does not disclose to the Identity Provider what attribute values are required for authorization. For security reasons, this setting may be preferable over the "values" setting. RequestFormat="all"—The setting omits attribute names and values from a query. The Identity Provider returns all user attributes and values, as long as the Identity Provider's Responder policies permit access to the attributes and values. This setting minimizes the number of attribute requests to one per user, but it uses the most cache memory. Use this setting if the Attribute Responder policies are configured to only return attributes that the Service Provider may want. This setting does not disclose to the Identity Provider what attributes are required for authoirzation. For security reasons, this may be preferable to the "values" and "names" settings.
Mappings of Subject DNs to Attribute Requester Service URLs.	The following parameters enable the Access System to determine if users are local—that is, if they have an identity in Oracle Access Manager—or remote and must be identified by an Attribute Requester Service. For remote users, these parameters map the subject DNs to a URL for your domain's (the Service Provider) instance of Oracle Identity Federation. For local users, authorization can be determined by the local Oracle Access Manager. You can configure following parameters: DN—One or more elements of a DN pattern to match against the user Subject DN in the request that the Access System receives. The pattern consists of the rightmost components of the DN, for example: O=MyCompany,L=MyCity,ST=California,C=US Local—If this parameter is true, the matching users are assumed to be local and the URL parameters are ignored. URL—The URL for the Oracle Identity Federation instance. The form is HTTP:// or HTTPS://OIF_host:OIF_port/fed/ar/soap Where OIF_host is the host name and OIF_port is the port of a local Oracle Identity Federation server. This is the server that receives requests from the Access System for verification of a user's attributes and forwards a SAML-formatted request to an Identity Provider's SAML services.

The following table provides examples of how subject DNs are evaluated according to the config.xml file. When Oracle Access Manager evaluates the Subject DN of a user, users who are deemed to be local are given local Oracle Access Manager credentials. All other users are referred to the attribute sharing authorization plug-in. Depending on the DNs of the remote users, a corresponding URL is used for sending a query to a local Oracle Identity Federation instance:

Table 5-2 Mappings of Subject DNs

User Subject DN	Mapping
E=[e-mail],CN=John Smith,OU=Engg,O=MyCompany, L=MyCity,ST=California,C=US	local
E=[e-mail], CN=Margaret Abel, OU=Test,O=MyCompany, L=MyCity, ST=California,C=US	https://host1.us.company.com:8888/fed/ar/soap
E=[e-mail], CN=Fred Jones, OU=Sales,O=OtherCompany, L=OtherCity,ST=Iowa,C=US	https://host2.us.company.com:8777/fed/ar/soap
E=[e-mail], CN=Mahitha Chandra,OU=Sales,O=OtherCompany, L=OtherCity,ST=TamilNadu,C=IN	https://host2.us.company.com:8777/fed/ar/soap

To configure the config.xml file:

1. Log in to the Access Server host as the user who installed the Access Server.

2. Create a file named config.xml in this directory.

3. Edit the attributes and elements of the config.xml file in the following directory:

   AS_install_dir/access/oblix/config/attributePlugin

4. Restart the Access Server.

5.3.2 Configuring Basic Authentication

If you are using basic authentication between the plug-in and Oracle Identity Federation, you need to add the following to the httpd.conf file of the Oracle HTTP Server for your Oracle Identity Federation instance. The following shows Basic authentication for a user named "Alice":

<LocationMath "/fed/ar/soap">
     Allow Override None
     AuthType Basic
     AuthName "Restricted Files"
     AuthUserFile /private/oifpassword
     Require user alice
     Order allow,deny
     Allow from all
</LocationMatch>

A user passwords file must also be created using the htpasswd utility. In the previous example, the AuthUserFile containing the users and their passwords points to the/private/oifpassword file, in which the user alice is defined. This example creates such a file by adding the user alice:

Apache/Apache/bin/htpasswd -c /private/oifpassword "alice"

Set the authn parameter to basic in "Setting Parameters in the config.xml File", and set the other required authentication parameters.

Finally, restart the Access Server.

5.3.3 Configuring SSL and Client Certificate Authentication

To send and receive information over a secure channel, you can configure SSL and client certificate authentication. You would select the type of secure channel as follows:

• HTTPS—Configure HTTPS if you specified HTTPs in the config.xml file and have configured HTTPS between the authorization plug-in and t at least one instance of Oracle Identity Federation. Configuring HTTPS involves pasting the CA certificate for each trusted Oracle Identity Federation instance into the cacerts.pem file for the plug-in.

• Client certificate authentication—Configure client certificate authentication if you configured SSL client certificate authentication between the authorization plug-in and at least one instance of Oracle Identity Federation. Configuring client certificate authentication involves generating a private key, requesting a new certificate, and pasting the certificate into cert.pem.

To set up HTTPS

1. Go to the wallet of the Oracle Identity Federation instance and export the CA certificate.

2. Open the exported file in a text editor and copy the contents, including the ----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- statements.

3. In another text editor, open the following file:

   AS_install_dir/oblix/config/attributePlugin/cacerts.pem

4. Paste the information that you copied to the end of the cacerts.pem file.

5. Restart the Access Server.

To set up client certificate authentication

1. Generate the private key and certificate request using the openssl command provided with Oracle Access Manager:

   cd AS_install_dir/oblix/tools/openssl

   openssl req -config openssl.cnf -newkey rsa:1024 -keyout ../../config/attributePlugin/key.pem - out ../../config/attributePlugin/req.pem

2. Send the req.pem file produced in the previous step to your CA to get a certificate.

3. Copy the generated certificate to the following location:

   AS_install_dir/oblix/config/attributePlugin/cert.pem

4. Change the mode to "cert" in the following file:

   AS_install_dir/oblix/config/attributePlugin/config.xml

5. Set the authn parameter to cert in "Setting Parameters in the config.xml File" on page 5-4, and set the other required authentication parameters.

6. Restart the Access Server.

5.3.4 Configure the Session Token Cache for Federated Attribute Sharing

The federated attribute sharing feature requires that an authentication be performed on each request. The authentication creates a new session token that is not actually used by the attribute sharing feature. However, the session token can be cached in the Access Server.

If all of your users authenticate using the attribute sharing authentication scheme, you can disable the session token cache to minimize the amount of memory used by the Access Server. If some users authenticate using other authentication schemes, you should enable the session token cache. See the section on Access Server configuration parameters in the Oracle Access Manager Access System Administration Guide for details.

Set the maximum number of elements in the session token cache to balance Access Server memory usage and performance requirements. A large value for this cache increases memory usage. A small value for the cache reduces memory usage but can cause the cache to fill up quickly with unused tokens from the attribute sharing scheme, resulting in performance degradation because the cache is always full.

5.4 Configuring the Authentication Scheme for Attribute Sharing

The attribute sharing authentication scheme consists of the following:

• Basic characteristics, including a name and the X509Cert authentication method.

• An authentication step to handle a local user.

  If the user is local, Oracle Access Manager can provide the attributes required for authorization.

• An authentication step to handle a remote user.

  This step sets an OblixAnonymous login for the user.

This section discusses the following topics:

• Configuring the Basic Components of the Authentication Scheme

• Configuring Plug-ins and Steps for the Authentication Scheme

5.4.1 Configuring the Basic Components of the Authentication Scheme

The basic components of the authentication scheme include defining the name of the scheme, its authentication level, and challenge method.

To configure the basic characteristics of the attribute sharing authentication scheme

1. Log in to the Access System Console as a Master Access Administrator.

2. Select the Access System Configuration tab.

3. Click Authentication Management in the left navigation pane.

   The Authentication Management: List All Authentication Schemes page appears.

4. Click Add.

5. Define a new authentication scheme with the following parameters:

   Name—OIF Attribute Sharing

   Description—Performs an SSL client certificate authentication for OIF Attribute Sharing authorization.

   Level—Set this value based on the requirements of the protected resources. The level should be higher than any password schemes.

   Challenge Method—Select the X509Cert option.

   Challenge Parameter—Enter the following in this field:

   ssoCookie:Expires=Tue, 1 Nov 2005 00:00:00 GMT

   This ensures that the authentication scheme is run on every access to protected resources. The challenge parameter forces the browser to discard the obSSOCookie, which forces a re-authentication.

   SSL Required—Select Yes.

   Enabled—Select No (set this to Yes after the plug-ins are configured).

6. Click Save.

5.4.2 Configuring Plug-ins and Steps for the Authentication Scheme

After defining the authentication scheme, you need to add plug-ins to the scheme. The plug-ins evaluate user credentials and create an appropriate Oracle Access Manager session for the user. You also need to configure the flow of plug-in evaluation.

To configure the plug-ins for the attribute sharing authentication scheme:

1. After completing the steps in "To configure the basic characteristics of the attribute sharing authentication scheme", select the Plugins tab.

2. Click Modify.

3. Add the following plug-ins and parameters.

   To enter built-in plug-ins, select the plug-in name from the list. To enter custom plug-ins, select Custom Plugin from the Plugin Name list and enter the plug-in name in the text box.

   Table 5-3 Plug-in Descriptions

   Plug-in Name	Type	Parameters
   authz_attribute	custom	Leave this field blank. This plug-in extracts the Subject DN field from the certificate and determines if the user is local or remote. Although this is a custom plug-in, the plug-in code is provided by Oracle. When an authentication scheme includes this plug-in in a step, the step calls a function in the plug-in library AS_install_dir/access/oblix/lib/authz_attribute.so or .dll. Note that this is the same library used by the authorization plug-in described later. Built-in plug-ins such as credential_mapping and decode_cert consist of code within the Access Server, and have no externally visible libraries.
   cert_decode	built-in	Leave this field blank. This plug-in addresses client certificate (cert) authentication by validating the certificate. It does not use a data source.
   credential_mapping	built-in	Add plug-in parameters using the following syntax. This plug-in assigns an OblixAnonymous login to a remote user. The user_ID attribute is the login attribute defined for Oracle Access Manager. You can use the credential_mapping parameters from the Anonymous authentication scheme if it is available. obMappingBase="mapping_base", obMappingFilter="(user_id=OblixAnonymous)" Example: obMappingBase="o=Company,c=US", obMappingFilter="(uid=OblixAnonymous)"
   credential_mapping	built-in	Add plug-in parameters using the following syntax. This plug-in determines if the user is active, and if so, creates a session for the user. obMappingBase="mapping_base", obMappingFilter="(&(& (objectclass=person_object_class) (user_attribute=%certSubject.field%)) (|(!(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))" Example: obMappingBase="o=Company,c=US", obMappingFilter=" (&(&(objectclass=inetorgperson) (mail=%certSubject.E%)) (|(!(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))"

   
   

4. When all the plug-ins have been added, click Save.

To configure the steps for the attribute sharing authentication scheme

1. After completing the tasks in "To configure the plug-ins for the attribute sharing authentication scheme:", select the steps panel, click Add, and add the following steps:

   Table 5-4 Step Configuration

   Step Name	Add Plug-In or Plug-Ins	Purpose of this Step
   SubjectDN	authz_attribute	Extract the SubjectDN from the certificate and determine if the user is remote or local.
   RemoteUser	first credential_mapping plug-in	Create an anonymous session for a remote user.
   LocalUser	cert_decode plug-in second credential_mapping plug-in	Create a real session for a local user.

   
   

2. Select the Authentication Flow tab, click Modify, and set the following flow.

   The authz_attribute plug-in returns Success if the user is remote and Failure if the user is local. Remote users are assigned the OblixAnonymous login and the attribute sharing authorization scheme is invoked. For local users, a session that applies to that user is assigned.

   Table 5-5 Authentication Flow Configuration

   Step Name	Initiating Step	On Success, the Next Step Is. . .	On Failure, the Next Step Is. . .
   Default Step	No	Stop	Stop
   SubjectDN	Yes	RemoteUser	LocalUser
   RemoteUser	No	Stop	Stop
   LocalUser	No	Stop	Stop

   
   

3. Return to the Steps tab and remove the Default step.

4. Return to the General tab and enable the authentication scheme.

5.5 Configuring the Authorization Schemes and Policies for Attribute Sharing

The attribute sharing authentication scheme determines whether a user is local or remote. If the user is local, the user is logged in to Oracle Access Manager, and an authorization scheme determines the user's access permissions. If the user is found to be remote and more information is needed, an authorization plug-in sends a request to one or more local instances of Oracle Identity Federation.

The local instances of Oracle Identity Federation request verification of the remote user's identity from the instance of Oracle Identity Federation at the Identity Provider site for the user. The local instances of Oracle Identity Federation also return the values to Oracle Access Manager and an access decision is made based on the user attributes that are returned. The returned attributes are specified in the ruleExpression in the authorization rule.

The authorization plug-in maintains a cache of previously retrieved user attributes. If the user attributes that are required for authorization are already stored in the cache, these are used instead of sending a request for the values to the Oracle Identity Federation instance. This reduces the number of attribute requests for subsequent authorizations that require the same attributes.

An attribute sharing policy determines what resources are to be protected, the order of authorization rule evaluation, and the authentication and authorization schemes that apply to the protected resources.

This section discusses the following topics:

• Configuring Basic Characteristics of the Authorization Scheme

• Configuring Rules and Policies for the Attribute Sharing Authorization Scheme

Note:

In the following sections, the authorization rules evaluate individuals. This has been done to simplify the examples. It is likely that in practice these rules would select a set of users, for example jobTitle = "Manager" & clearance = "Secret", or OU = "Server Development Team".

5.5.1 Configuring Basic Characteristics of the Authorization Scheme

Basic characteristics of the authorization scheme include a name and a required parameter named ruleExpression, which is defined in "Configuring Rules and Policies for the Attribute Sharing Authorization Scheme". In addition to creating a basic definition for the authorization rule, you need to indicate what resources this rule protects.

To configure basic characteristics of the attribute sharing authorization scheme:

1. Log in to the Access System Console as a Master Access Administrator.

2. Click the Access System Configuration tab.

3. Click Authorization Management in the left navigation pane.

4. Click Add.

   The Define a New Authorization Scheme page appears.

5. Enter the following:

   Name—OIF Attribute Sharing (or any other appropriate name).

   Description—Uses OIF to obtain attributes for remote users to evaluate the rule expression.

   Shared Library—Enter the following: oblix/lib/authz_attribute

   Plugin is Managed Code—Select No.

   Managed Code Name Space—Leave this field blank.

   User Parameter—Enter the following: RA_SubjectDN

   This value invokes an external query function to obtain the SubjectDN header that is set by the authz_attribute authentication plug-in. See the section on retrieving external data for an authorization request in the Oracle Access Manager Access System Administration Guide for details.

   Required Parameter—Enter ruleExpression in the Name field. Leave the Value field blank. Each access policy authorization rule will supply the rule expression.

6. Click Save.

To configure the protected resources in an attribute sharing access policy

1. Log in to the Policy Manager as a Master or Delegated Access Administrator.

2. Select Create Policy Domain.

3. Complete the General page, as follows:

   Name—Provide a unique name, for example, OSFS Attribute Sharing Test.

   Description—Provide an appropriate description.

4. Click Save.

5. Click the Resource tab and add one or more URL prefixes to protect.

   Example: /attribute-test

5.5.2 Configuring Rules and Policies for the Attribute Sharing Authorization Scheme

After defining the authentication scheme and protected resources for the scheme, you need to do the following:

• Define rules that determine who is authorized to access the protected resources.

  These rules contain expressions that parse user attributes and sets of attributes. The rules provide yes-or-no decisions based on the presence or absence of these attributes or sets of attributes in the user's credentials.

  You can create different rules for local and remote users.

• Define the evaluation order of these rules in the authorization policy, and create a default rule to apply if none of the other rules can be used when performing an authorization.

• Associate the policy with the attribute sharing authentication scheme as well as the attribute sharing authorization scheme.

To configure an authorization rule for remote users in an attribute sharing access policy

1. After completing the steps in "To configure an authorization rule for remote users in an attribute sharing access policy", click the Authorization Rules tab, then click Add.

   Each rule is represented as an expression.

2. Select Custom Authorization Scheme, click Add, and fill out the form as follows:

   Name—Provide an appropriate name, for example, Remote User 1.

   Description—Provide a description that will help others understand this rule.

   Authorization Scheme—OIF Attribute Sharing.

3. Click the Plugin Parameters tab, click Modify, and define the rule expression.

   In the Name field, enter the following name: ruleExpression.

   In the Value field, provide a value that the Identity Provider is to search for. The value can be an expression. Use the minus ("-") and plus ("+") buttons to add expressions.

   White space is allowed around the equals sign ("="), bang equals ("!="), ampersand ("&"), and or operator ("|"). Table 5-6 lists the available parameters.

   Examples of rule expressions:

   firstname="John" & lastname="Smith"

   firstname="Conserving" & lastname="Levitin"|firstname="Mahitha" & lastname = "Valiveti"

   firstname = "Charles" & (lastname = "Smith"|lastname="Chandra")

   firstname=any & lastname=any.

   Table 5-6 Expression Parameters for a Rule

   Element	Syntax	Description
   name	alphanumeric string including dash ("-"), underscore ("_"), and period (".").	Name of an attribute to request from the user's Identity Provider.
   value	one of "string", any, or null	Required attribute value. The string is restricted to Latin-1 characters. The any value retrieves and matches all values for the attribute. The null value matches a SAML <Attribute> with the xsi:nil="true" attribute.
   comparison	name = value, name! = value, or (expression).	True if the user has or does not have the attribute value.
   and-clause	comparison & comparison	True if both comparisons are true.
   or-clause	comparison | comparison	True if either comparison is true. the ampersand ("&") has a higher precedence than the vertical bar ("|").

   
   

4. Save the authorization rule form.

5. Set any timing conditions or actions for the authorization rule.

6. Click the General tab and click Modify.

7. Select Yes in the Enabled list to enable the rule.

To configure an authorization rule for local users in an attribute sharing access policy

1. After completing the steps in "To configure an authorization rule for local users in an attribute sharing access policy", click the Authorization Rules tab.

2. To add an authorization rule for each set of local user attributes, click Add.

3. In the Authorization Scheme list, select Oracle Authorization Scheme, then click Add.

4. Complete the authorization rule form as follows:

   Name—Provide an appropriate name, for example, User 1 Local.

   Description—Provide a description that will help others understand the rule.

   Enabled—Select Yes.

   Allow Takes Precedence—Select No.

5. Save the form.

6. Select the Allow Access tab and click Add.

   Add an LDAP filter for the local attributes.

   You can use the Query Builder in the Identity System's User Manager application to build the filter. (From the Identity System Console, click Configuration, then click Delegate Administration, then click Build Filter.) The following is an example of a filter:

   ldap:///o=Company,c=US??sub?(&(givenname=Rohit)(sn=Valiveti))

7. Set any timing conditions or actions as required for the authorization rule.

8. Click the General tab and click Modify.

9. Select Yes in the Enabled list to enable the rule.

To configure a rule expression in an attribute sharing access policy

1. After completing the steps in "To configure an authorization rule for local users in an attribute sharing access policy", select the Default Rules tab.

2. Add the default authentication rule as follows:

   Name—An appropriate name, for instance, Default Rule

   Description—A meaningful description.

   Authentication Scheme—Select the OSFS Attribute Sharing authentication scheme.

3. Save the rule.

4. Select the Authorization Expression tab.

5. Select the remote authorization rule and click Add.

6. Select the local authorization rule, select OR, and add it. For example:

   Remote User 1 | Local User 2

7. Save the authorization rule.