Securing WebLogic Server
This section explains how to set up single sign-on (SSO) with Microsoft clients, using Windows authentication based on the Simple and Protected Negotiate (SPNEGO) mechanism and the Kerberos protocol, together with the WebLogic Negotiate Identity Assertion provider.
Single sign-on (SSO) with Microsoft clients allows cross-platform authentication between Web applications or Web Services running in a WebLogic Server domain and .NET Web Service clients or browser clients (for example, Internet Explorer) in a Microsoft domain. The Microsoft clients must use Windows authentication based on the Simple and Protected Negotiate (SPNEGO) mechanism.
Cross-platform authentication is achieved by emulating the negotiate behavior of native Windows-to-Windows authentication services that use the Kerberos protocol. In order for cross-platform authentication to work, non-Windows servers (in this case, WebLogic Server) need to parse SPNEGO tokens in order to extract Kerberos tokens which are then used for authentication.
Configuring SSO with Microsoft clients involves set up procedures in the Microsoft Active Directory, the client, and the WebLogic Server domains.
The main configuration steps are as follows:
For more information, see Creating a Kerberos Identification for WebLogic Server.
The following sections describe these steps in detail.
To use SSO with Microsoft clients, you must comply with these system requirements:
A Windows domain controller can server as the Kerberos Key Distribution Center (KDC), using the Active Directory and the Kerberos services. On any domain controller, the Active Directory and the Kerberos services will be running automatically. To configure Kerberos in your Windows domain controller, you need to configure each machine that will access the KDC to locate the Kerberos realm and available KDC servers. For Windows machines, this configuration is in the krb5.ini
file, in the C:\winnt
folder. For UNIX machines, this configuration is in the krb5.conf
file, the default location of which is /etc/krb5/
. For example:
Listing 6-1 Sample krb5.ini File
[libdefaults]
default_realm = MYDOM.COM (Identifies the default realm. Set its value to your Kerberos realm)
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
ticket_lifetime = 600
[realms]
MYDOM.COM = {
kdc = <IP address for MachineA> (host running the KDC)
(For Unix systems, you need to specify port88, as in <IP-address>:88)
admin_server = MachineA
default_domain = MYDOM.COM
[domain_realm]
.mydom.com = MYDOM.COM
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true
Active Directory provides support for service principal names (SPN) which are a key component in Kerberos authentication. SPNs are unique identifiers for services running on servers. Every service that uses Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. An SPN usually looks something like name@YOUR.REALM. You need to define an SPN to represent your WebLogic Server in the Kerberos realm. If an SPN is not set for a service, clients have no way of locating that service. Without correctly set SPNs, Kerberos authentication is not possible. Keytab files are the mechanism for storing the SPNs. Keytab files are copied to the WebLogic Server domain and are used in the login process. This configuration step describes how to create an SPN, user mapping, and keytab file for WebLogic Server.
This configuration step requires the use of the following Active Directory utilities:
Note: The setspn
and ktpass
Active Directory utilities are products of Microsoft. Therefore, BEA Systems does not provide complete documentation for this utilities. For more information, see the appropriate Microsoft documentation.
To create a Kerberos identification for WebLogic Server:
When creating the user account, use the simple name of the computer. For example, if the host is named myhost.example.com
, create a user in Active Directory called myhost.
Note the password you defined when creating the user account. You will need it in step 3. Do not select the User must change password at next logon
option, or any other password options.
setspn
utility to create the Service Principal Names (SPNs) for the user account created in step 1. Enter the following commands:setspn -a host/
myhost.example.com myhost
setspn -a HTTP/
myhost.example.com myhost
setspn -L
account name
This is an important step. If the same service is linked to a different account in the Active Directory server, the client will not send a Kerberos ticket to the server.
Windowsktpass -princ host/
myhost@Example.CORP -pass
password -mapuser myhost -out c:\temp\myhost.host.keytab
ktab
utility manages principal name and key pairs in the key table and allows you to list, add, update, or delete principal names and key pairs. On UNIX, it is preferable to use the ktpass
utility.
ktpass -princ HTTP/
myhost@Example.CORP
-pass
password
-mapuser myhost -out c:\temp\myhost.HTTP.keytab
where password is the password for the user account created in step 1.
ktutil: "rkt myhost.host.keytab"
ktutil: "rkt myhost.HTTP.keytab"
ktutil: "wkt mykeytab"
ktutil: "q"
kinit -k -t
keytab-file
account-name
Ensure the Microsoft client you want to use for single sign-on is configured to use Windows Integrated authentication. The following sections describe how to configure a .NET Web server and an Internet Explorer browser to use Windows Integrated authentication.
To configure a .NET Web Service to use Windows authentication, perform the following steps:
web.config
file for the Web Service, set the authentication mode to Windows for IIS and ASP.NET as follows:<authentication mode="Windows" />
To configure an Internet Explorer browser to use Windows authentication, follow these procedures in Internet Explorer:
If you have a proxy server enabled:
In addition to the previous settings, one additional setting is required if you are running Internet Explorer 6.0.
If you are running WebLogic Server on either the Windows or UNIX platforms, you need a JAAS login file. The JAAS login file tells the WebLogic security framework to use Kerberos authentication and defines the location of the keytab file which contains Kerberos identification information for WebLogic Server. You specify the location of this file in the java.security.auth.login.config startup argument for WebLogic Server, as described in Startup Arguments for Using Kerberos Authentication with WebLogic Server.
Listing 6-2 contains a sample JAAS login file for Kerberos authentication.
Listing 6-2 Sample JAAS Login File for Kerberos Authentication
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
principal="myhost@Example.CORP
" useKeyTab=true
keyTab=mykeytab
storeKey=true;
};
com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule required
principal="myhost@Example.CORP
" useKeyTab=true
keyTab=mykeytab
storeKey=true;
};
WebLogic Server includes a security provider, the Negotiate Identity Assertion provider, to support single sign-on (SSO) with Microsoft clients. This identity assertion provider decodes Simple and Protected Negotiate (SPNEGO) tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps Kerberos tokens to WebLogic users. You need to configure a Negotiate Identity Assertion provider in your WebLogic security realm in order to enable SSO with Microsoft clients. For information, see Configuring a Negotiate Identity Assertion Provider and Configure Authentication and Identity Assertion providers in the Administration Console help.
To use Kerberos authentication with WebLogic Server, use the following start-up arguments when you start WebLogic Server:
-Djava.security.krb5.realm=
Example.COR
P
-Djava.security.krb5.kdc=ADhostname
-Djava.security.auth.login.config=krb5Login.conf
-Djavax.security.auth.useSubjectCredsOnly=false
-Dweblogic.security.enableNegotiate=true
weblogic.security.enableNegotiate enables the Servlet container in WebLogic Server to support the Negotiate token used by SPNEGO.
To verify that SSO with Microsoft clients is properly configured, point a browser (that you have configured as described in Configuring an Internet Explorer Browser) to the Microsoft Web application or Web Service you want to use. If you are logged on to a Windows domain and have Kerberos credentials acquired from the Active Directory server in the domain, you should be able to access the Web application or Web Service without providing a username or password.