In
Figure 5-3 , the user logs into PR1 at time 0, then logs into PR2 at time 6. During the next 30
minutes, the user is active on PR1. The time line for the shared1 activity realm is updated with the user’s activity. The user then access PR2 at time 38. Even though no activity has taken place on PR2 for more than the 15-minute contract timeout, PR2 does not time out because activity has occurred within this time at PR1 and because the resources share the same activity realm. Assigning two or more contracts to the same activity realm allows the contracts to influence the timeouts of the other contracts in the activity realm.
When you configure protected resources to use different contracts with different timeouts, they can keep each other alive when they share the same activity realm. If protected resources must not affect each other's activity, they must not share a common activity realm.
You can assign a contract to multiple activity realms. With this configuration, activity on a resource updates the time lines of all activity realms associated with the contract. As long as one of the activity realms has activity within the contract’s timeout limit, the user’s session remains authenticated.
Activity realms are defined by specifying a name, and the names are case insensitive. Use a commaseparated list to specify multiple names. The system has two default realms that you can use:
Any:
Leave the field blank or specify any when you want the user’s session to remain alive as long as there is some activity by the user at the Access Gateway or at the Identity Server.
When the Identity Server receives an assertion from another Identity Server that cannot be mapped to a contract, the activity realm is set to any with the timeout value equal to the value of the Tomcat session. (The Tomcat session timout is set to the greatest timeout value of the contracts configured for the Identity Server.)
NIDPActivity:
Specify NIDPActivity for the realm when any activity at the Identity Server by the user can be used to keep the user’s session alive.
When you place multiple contracts in the same activity realm, you need to plan carefully so that security limits aren’t overruled by activity on less critical protected resources. You also need to carefully balance the desire for single sign-on with the need to require reauthentication for sensitive data. Highly sensitive resources are most secure when they are protected by a contract that is created from its own unique method and that is assigned its own unique activity realm. For more information, see
“Assigning a Timeout Per Protected Resource” on page 110
.
Specifying Authentication Defaults
You can specify default values for how the system processes user stores and authentication contracts. The default contract is executed when users access the system without a specified contract, and when the Access Gateway is configured to use any authentication.
Additional default contracts can be specified for well-known authentication types that might be required by a service provider. These contracts are executed when a request for a specific authentication type comes from a service provider.
1
In the Administration Console, click
Devices > Identity Servers > Edit > Local > Defaults.
2
Configure the following fields as necessary:
User Store:
Specifies the default user store for local authentication. If you selected
<Default
User Store>
when configuring an authentication method, the system uses the user store you specify here.
Authentication Contract:
Specifies the default authentication contract to be used when users access the Identity Server directly or a protected resource is configured to use
Any Contract
. If you create a new contract and specify it as the default, ensure that you update the Access
Gateway configuration if it has protected resources configured to use
Any Contract
.
296
Configuring Authentication
Authentication Type:
Specifies the default authentication contracts to be used for each authentication type. When a service provider requests a specific authentication type, rather than a contract, the identity provider uses the authentication contract specified here for the requested
authentication type. For more information, see “Specifying Authentication Types” on page 298
.
3
Click
OK
.
4
Update the Identity Server.
Specifying Authentication Types
Trusted service providers can send the Identity Server an authentication request that contains a request for contract or for an authentication type. When the request is for an authentication type, the
Identity Server must translate the type to a contract before authenticating the user. You can use the
Authentication Type
section of the Defaults page to specify which contract to use for the common types (classes).
The Identity Server has not implemented all possible types. For types that do not appear on the
Defaults page, you can do one of the following:
You can define a contract for the class whose URI matches the requested class type. When the authentication request is received, the Identity Server uses the URI to match the request with a contract.
When you create such a contract, you are stating that the contract is security equivalent to the
class that is being requested. For configuration information, see “Creating a Contract for a
Specific Authentication Type” on page 298
.
You can use the Trust Levels class to assign an authentication level for the requested class. This level is used to rank the requested type. Using the authentication level and the comparison context, the Identity Server can determine whether any contracts meet the requirements of the request. If one or more contracts match the request, the user is presented with the appropriate authentication prompts.
For configuration information, see “Configuring the Trust Levels Class” on page 149 .
Creating a Contract for a Specific Authentication Type
The following steps explain how to create a contract that matches what a trusted service provider is asking for in its authentication request.
1
In the Administration Console, click
Devices > Identity Servers > Edit > Local > Contracts
.
2
To create a new contract, click
New
.
3
Fill in the following fields:
Display name:
Specifies the name of the authentication contract.
URI:
Specifies a value that uniquely identifies the contract from all other contracts. This value must match what the service provider is sending in its authentication request for the type.
Authentication Level:
(Optional) Specify a security level or rank for the contract. This value is not used when authentication request sets the comparison type to exact. It is only used when a contract is selected based on a comparison of authentication levels.
If the service provider sets the comparison type to minimum, the authentication level can be the same or higher. If the comparison type is set to better, the authentication level must be higher.
Methods:
Select the method that matches the class or type you specified in the URI.
Configuring Authentication
297
