| Oracle® Communications Converged Application Server Administration Guide Release 5.0 Part Number E17647-03 |
|
|
View PDF |
| Oracle® Communications Converged Application Server Administration Guide Release 5.0 Part Number E17647-03 |
|
|
View PDF |
This chapter describes how to configure Oracle Communications Converged Application Server to use Client-Cert authentication:
Configuring Converged Application Server to Use WL-Proxy-Client-Cert
Supporting Perimeter Authentication with a Custom IA Provider
Client-Cert authentication uses a certificate or other custom tokens in order to authenticate a user. The token is "mapped" to a user present in the Converged Application Server security realm in which the Servlet is deployed. SIP Servlets that want to use Client-Cert authentication must set the auth-method element to CLIENT-CERT in their sip.xml deployment descriptor.
The token used for Client-Cert authentication can be obtained in several different ways:
X509 Certificate from SSL: In the most common case, an X509 certificate is derived from a client token during a two-way SSL handshake between the client and the server. The SIP Servlet can view the resulting certificate in the javax.servlet.request.X509Certificate request attribute. This method for performing Client-Cert authentication is the most common and is described in the SIP Servlet specification (JSR-116). Converged Application Server provides two security providers that can be used to validate the X509 certificate; see "Configuring SSL and X509 for Converged Application Server".
WL-Proxy-Client-Cert Header: Converged Application Server provides an alternate method for supplying a Client-Cert token that does not require a two-way SSL handshake between the client and server. Instead, the SSL handshake can be performed between a client and a proxy server or load balancer before reaching the destination Converged Application Server. The proxy generates the resulting X509 certificate chain and encrypts it using base-64 encoding, and finally adds it to a special WL-Proxy-Client-Cert header in the SIP message. The server hosting the destination SIP Servlet then uses the WL-Proxy-Client-Cert header to obtain the certificate. The certificate is also made available by the container to Servlets via the javax.servlet.request.X509Certificate request attribute.
To use this alternate method of supplying client tokens, you must configure Converged Application Server to enable use of the WL-Proxy-Client-Cert header; see "Configuring Converged Application Server to Use WL-Proxy-Client-Cert". You must also configure an X509 Identity Asserter provider as described in "Configuring SSL and X509 for Converged Application Server".
SIP Servlets can also use the CLIENT-CERT auth-method to implement perimeter authentication. Perimeter authentication uses custom token names and values, along with a custom security provider, to authenticate clients. See "Supporting Perimeter Authentication with a Custom IA Provider" for a summary of steps required to implement perimeter authentication.
Converged Application Server includes two separate Identity Assertion providers that can be used with X509 certificates. The LDAP X509 Identity Asserter provider receives an X509 certificate, looks up the LDAP object for the user associated with that certificate in a separate LDAP store, ensures that the certificate in the LDAP object matches the presented certificate, and then retrieves the name of the user from the LDAP object. The Default Identity Asserter provider maps the user according to its configuration, but does not validate the certificate.
With either provider, Converged Application Server uses two-way SSL to verify the digital certificate supplied by the client. You must ensure that a SIPS transport (SSL) has been configured in order to use Client-Cert authentication. See Chapter 21, "Managing Network Resources," if you have not yet configured a secure transport.
See "Configuring the Default Identity Asserter" to configure the Default Identity Asserter provider. In most production installations you will have a separate LDAP store and will need to configure the LDAP X509 Identity Asserter provider to use client-cert authentication; see "Configuring the LDAP X509 Identity Asserter".
The Default Identity Asserter can be configured to verify an X509 certificate passed to it by a client over a secure (SSL) connection. The Default Identity Asserter requires a separate user name mapper to map the associated client "certificate" to a user configured in the default security realm. You can use the default user name mapper installed with Converged Application Server, or you can create a custom user name mapper class. See the chapters on configuring a WebLogic credential mapping provider in Securing Oracle WebLogic Server the Oracle WebLogic Server 11g Documentation for information on creating a custom user name mapper class.
Follow these instructions to configure the Default Identity Asserter:
Log in to the Administration Console for the Converged Application Server domain you want to configure.
In the left pane of the Console, select the Security Realms node.
Select the name of your security realm in the right pane of the Console. (for example, myrealm).
Select the Providers > Authentication tab.
In the right pane of the Console, select DefaultIdentityAsserter from the table of configured providers.
On the Configuration > Common page, select X.509 in the Available column of the Active Types table and use the arrow to move it to the Chosen column.
Click Save to apply the change.
You can use either a custom Java class to map names in the X509 certificate to user names in the built-in LDAP store, or you can use the default user name mapper. To specify a custom Java class to perform user name mapping:
Select the Configuration > Provider Specific tab.
Enter the name of the custom class in the User Name Mapper Class Name field.
Click Save.
To use the default user name mapper:
Select the Configuration > Provider Specific tab.
Select Use Default User Name Mapper.
In the Default User Name Mapper Attribute Type list, select either CN (for Common Name) or E (for Email address) depending on the user name attribute you have stored in the security realm.
In the Default User Name Mapper Attribute Delimiter field, accept the default delimiter of "@". This delimiter is used with the E (Email address) attribute type to extract the email portion from the client token. For example, a token of "joe@mycompany.com" would be mapped to a username "joe" configured in the default security realm.
Click Save.
Follow these steps to create and configure the X509 Authentication Provider.
Log in to the Administration Console for the Converged Application Server domain you want to configure.
In the left pane of the Console, select the Security Realms node.
Select the name of your security realm in the right pane of the Console. (for example, "myrealm").
Select Providers, then select the Authentication tab.
Click New.
Enter a name for the new provider, and select "LDAPX509IdentityAsserter" as the type.
Click OK.
In the list of providers, select the name of the provider you just created.
In the Configuration > Provider Specific tab, enter LDAP server information into the fields as follows:
User Field Attributes: Enter an LDAP search filter that Converged Application Server will use to locate a given username. The filter is applied to LDAP objects beneath the base DN defined in the Certificate Mapping attribute described below.
User Name Attribute: Enter the LDAP attribute that stores the user's name.
Certificate Attribute: Enter the LDAP attribute that stores the certificate for the user name.
Certificate Mapping: Specify how a query string to construct the base LDAP DN used to locate the LDAP object for the user.
Host: Enter the host name of the LDAP server to verify the incoming certificate. If you are using multiple LDAP servers for failover capabilities, enter the host name:port value for each server separated by spaces. For example: ldap1.mycompany.com:1050 ldap2.mycompany.com:1050
See Securing Oracle WebLogic Server in the Oracle WebLogic Server documentation for more information about configuring failover.
Port: Enter the port number of the LDAP server.
SSL Enabled: Select this option if you are using SSL to communicate unencrypted passwords between Converged Application Server and the LDAP Server.
Principal: Enter the name of a principal that Converged Application Server uses to access the LDAP server.
Credential: Enter the credential for the above principal name (generally a password).
Confirm Credential: Re-enter the principal's credential.
Cache Enabled: Specifies whether a cache should be used with the associated LDAP server.
Cache Size: Specifies the size of the cache, in Kilobytes, used to store results from the LDAP server. By default the cache size is 32K.
Cache TTL: Specifies the time-to-live (TTL) value, in seconds, for the LDAP cache. By default the TTL value is 60 seconds.
Follow Referrals: Select this to specify that a search for a user or group within the LDAP X509 Identity Assertion provider should follow referrals to other LDAP servers or branches within the LDAP directory.
Bind Anonymously On Referrals: By default, the LDAP X509 Identity Assertion provider uses the same DN and password used to connect to the LDAP server when following referrals during a search. If you want to connect as an anonymous user, check this box.
Results Time Limit: Specifies the number of milliseconds to wait for LDAP results before timing out. Accept the default value of 0 to specify no time limit.
Connect Timeout: Specifies the number of milliseconds to wait for an LDAP connection to be established. If the time is exceeded, the connection times out. The default value of 0 specifies no timeout value.
Parallel Connect Delay: Specifies the number of seconds to delay before making concurrent connections to multiple, configured LDAP servers. If this value is set to 0, the provider connects to multiple servers in a serial fashion. The provider first tries to connect to the first configured LDAP server in the Host list. If that connection attempt fails, the provider tries the next configured server, and so on.
If this value is set to a non-zero value, the provider waits the specified number of seconds before spawning a new thread for an additional connection attempt. For example, if the value is set to 2, the provider first tries to connect to the first configured LDAP server in the Host list. After 2 seconds, if the connection has not yet been established, the provider spawns a new thread and tries to connect to the second server configured in the Host list, and so on for each configured LDAP server.
Connection Retry Limit: Specifies the number of times the provider tries to reestablish a connection to an LDAP server if the LDAP server throws an exception while creating a connection.
Click Save to save your changes.
Reboot the server to realize the changed security configuration.
In order for Converged Application Server to use the WL-Proxy-Client-Cert header, a proxy server or load balancer must first transmit the X509 certificate for a client request, encrypt it using base-64 encoding, and then add the resulting token WL-Proxy-Client-Cert header in the SIP message. If your system is configured in this way, you can enable the local Converged Application Server instance (or individual SIP Servlet instances) to examine the WL-Proxy-Client-Cert header for client tokens.
To configure the server instance to use the WL-Proxy-Client-Cert header:
Log in to the Administration Console for the Converged Application Server domain you want to configure.
In the left pane, select Environment, then select the Servers node.
Select the name of a configured engine tier server.
Select Configuration, then select the General tab in the right pane.
Select Client Cert Proxy Enabled.
Click Save to save your changes.
Follow the instructions under "Configuring SSL and X509 for Converged Application Server" to configure either the default identity asserter or the LDAP Identity Asserter provider to manage X509 certificates.
Reboot the server to realize the changed configuration.
To enable the WL-Proxy-Client-Cert header for an individual Web Application, set the com.bea.wcp.clientCertProxyEnabled context parameter to true in the application's sip.xml deployment descriptor.
With perimeter authentication, a system outside of WebLogic Server establishes trust via tokens. The system is generally comprised of an authentication agent that creates an artifact or token that must be presented to determine information about the authenticated user at a later time. The actual format of the token varies from vendor to vendor (for example, SAML or SPNEGO).
Converged Application Server supports perimeter authentication through the use of an Identity Assertion provider designed to recognize one or more token formats. When the authentication type of a SIP Servlet is set to CLIENT-CERT, the SIP container in Converged Application Server performs identity assertion on values from the request headers. If the header name matches the active token type for a configured provider, the value is passed to the provider for identity assertion.
The provider can then use a user name mapper to resolve the certificate to a user available in the security realm. The user corresponding to the Subject's Distinguished Name (SubjectDN) attribute in the client's digital certificate must be defined in the server's security realm; otherwise the client will not be allowed to access a protected WebLogic resource.
If you want to use custom tokens to pass client certificates for perimeter authentication, you must create and configure a custom Identity Assertion provider in place of the LDAP X509 or Default Identity Asserter providers described above. See Securing Oracle WebLogic Server in the Oracle WebLogic Server documentation for information about creating providers for handling tokens passed with perimeter authentication.
|
 Copyright © 2005, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
