1.2 How Access Manager Works

Access Manager deployments typically use Identity Servers and Access Gateways to provide policy-driven access control for HTTP services. For non-HTTP services, Access Manager provides secure VPN and J2EE Agent components.

Figure 1-1 illustrates the primary purposes of Access Manager: authentication, identity federation, authorization, and identity injection.

Figure 1-1 Access Manager

1.2.1 Authentication

The Identity Server facilitates authentication for all Access Manager components. This authentication is shared with internal or external service providers on behalf of the user, by means of assertions. Access Manager supports a number of authentication methods, such as name/password, RADIUS token-based authentication, X.509 digital certificates, Kerberos, and OpenID. You specify authentication methods in the contracts that you want to make available to the other components of Access Manager, such as the Access Gateway.

User data is stored in user stores. User stores are LDAP directory servers to which end users authenticate. You can configure a user store with more than one replica to provide load balancing and failover capability.

1.2.2 Authorization

Authentication is the process of determining who a user is. Authorization is the process of determining what a user is allowed to do. Access Manager allows you to configure roles and authorization policies, based on criteria other than authentication, to protect a resource. Authorization policies are dynamically applied after authentication and are enforced when a user attempts to access a protected resource.

1.2.3 Identity Injection

An Access Gateway lets you retrieve information from your LDAP directory, use it to inject information into HTML headers, query strings, or basic authentication headers, and send this information to the back-end Web servers. Access Manager calls this technology identity injection (iChain calls it object level access control). The Web server uses this information to personalize content, or can use it for additional authorization decisions. Where Web servers require additional authentication, Identity Injection can also provide the necessary credentials to perform a single sign-on.

1.2.4 Identity Federation

Identity federation is the association of accounts between an identity provider and a service provider. As shown in Figure 1-2, an employee named Steve is known as steve.s at his corporate identity provider. He has an account at a work-related service provider called 401k, which has set up a trust relationship with his company. At 401k he is known as ssmith_01.

Figure 1-2 Identity Federation

As a service provider, 401k can be configured to trust the authentication from the corporate identity provider. Steve can enable single sign-on and single logout by federating, or linking, his two accounts.

From an administrative perspective, this type of sharing reduces identity management costs, because multiple organizations do not need to independently collect and maintain identity-related data, such as passwords. From the end user’s perspective, this results in an enhanced experience by requiring fewer sign-ons.

1.2.5 SSL Renegotiation

SSL renegotiation is the process of establishing a new SSL handshake over an existing SSL connection. The renegotiation messages (ciphers and encryption keys) are encrypted and then sent over the existing SSL connection to establish another session securely and is useful in the following scenarios:

  • When you require a client authentication.

  • When you require a different set of encryption and decryption keys.

  • When you require a different set of encryption and hashing algorithms.

SSL renegotiation is enabled or disabled by the following parameter: "sun.security.ssl.allowUnsafeRenegotiation.

This is defined in a registry on Windows and a configuration file on SLES.

Registry key on Windows is [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\Tomcat7\Parameters\Java\Options]. (How to set the registry key)

Value data for the registry key to enable the SSL renegotiation on Windows is:

-Dsun.security.ssl.allowUnsafeRenegotiation=true (procedural format to enable the SSL renegotiation)

To disable the SSL renegotiation on Windows, remove the following entry:

"-Dsun.security.ssl.allowUnsafeRenegotiation=true"

Configuration file on SLES contains the following parameter:

/opt/novell/nam/idp/conf /tomcat7.conf

Value data for the registry key to enable the SSL renegotiation on SLES 11 SP2, or SP3 is:

"JAVA_OPTS="${JAVA_OPTS} -Dsun.security.ssl.allowUnsafeRenegotiation=true"

To disable the SSL renegotiation on SLES, remove the following entry:

"JAVA_OPTS="${JAVA_OPTS} -Dsun.security.ssl.allowUnsafeRenegotiation=true"

SSL renegotiation can be initiated either by the SSL client or the SSL server. Initiating an SSL renegotiation on the client or the server requires different set of APIs.