SSO Weblogic 8.1 – Kerberos – Active Directory 2003

This article describes the step configuration, but also a troubleshooting section where I mention how to debug the various stages of the SSO.

The SSO is the technique of only one single password for a user session even if it spans multiple servers or multiple domains. More specifically in our case, it is to recover the identity of a user of a Windows domain where it connects to a J2EE application server without having weblogic need to enter any login or password on the server. This operation is based on the use of protocol Kerberos proposed by the MIT. It is to use a trusted third party to carry out the phases of identifying a person (the Intranet) for a service (access to a resource weblogic).

Here is the sequence of interactions that come into play during the authentication:

IE -> Weblogic: The user requests a Web resource, such as a servlet in a web-app deployed on the server.However access to this servlet is configured to require authentication type SSO.

Weblogic -> IE: The weblogic server responds to IE it wants a Kerberos ticket in good and due form.

1. IE -> AD Kerberos on IE after verifying that the resource requests that the ticket is well within its area of trust, aimed at its primary domain controller and requests a ticket for the resource hosted by the HTTP server weblogic in question (the network address and the type of service is described in the application).
2. Kerberos in AD -> IE: Kerberos after verifying that the resource exists it responds by returning a ticket and only the HTTP service weblogic will be able to decrypt. The ticket was valid only during a short period of time to ensure that nobody can decrypt it and reuse it (the time of decryption toutefaçon was higher than the lifetime of the ticket).
3. IE -> Weblogic: IE receives the ticket from the KDC and automatically forward to Weblogic.
4. Weblogic -> Kerberos on AD: Weblogic checks with the Kerberos server that it is in the issuer. It then decrypts the ticket and obtains the user’s login of Active Directory that visits it.

Reference environment

To be as clear as possible here are the reference data used throughout this documentation:

• Active Directory: SDACLIN.FR
• Network Name Server Active Directory: serverad
• IP Active Directory server: 192.168.1.2
• Port Service kerberos: 88
• Network Name weblogic server: serverweblo
• Weblogic server IP: 192.168.1.3
• Login and CDM server console weblogic: weblogic: weblogic
• Name of the user to create in Active Directory: weblogicsrv
• SPN to be used by weblogic to contact the KDC: weblogicsrv@SDACLIN.FR
• SPN that IE users will use to reference the HTTP server weblo / serverweblo.sdaclin.fr @ SDACLIN.FR
• Address on which the webapp is deployed “Kerberos” test http://serverweblo:7001/Kerberos
• Network name of the client domain SDACLIN.FR: laptopsdaclin
• The client uses a version IE 6 SP2
• The serverAd is a windows server 2003
• The server version is weblogic weblogic 8.1 SP6, it uses a JVM jdk142_11 provided by BEA and runs on Windows XP SP2
  

Configuration Configuration

The configuration is done in 4 stages:

1. Step 1 – Create a dedicated user to the SSO in AD to represent the weblogic.
2. Step 2 – Adding a mapping between the user created in AD and a new service account compatible Kerberos to be used by weblogic.keytab sur le serveur weblogic. This mapping will then be exported as a. Keytab on the weblogic server.
3. Step 3 – Configure weblogic server to use the SSO
4. Step 4 – Creating a web-app test deploy on weblogic

Step 1 – Create a user in the AD (about serverad)

1. Creating a user for the weblogic server (this user will use to decode the KDC kerberos tokens and verify the identity of the user logged in).
   1. Launch Programs / Administrative Tools / Active Directory Users and Computers tool.
   2. Right-click the Users node and select New / User (Do not create a machine).
   3. Enter in the “Full Name” and “Logon Name” value weblogicsrv.
   4. Click Next and enter the password weblogicsrv.
   5. Option to ensure that no password is selected and click Next.
   6. Click Finish.
2. Changing User Properties AD:
   1. Identify the new user weblogicsrv
   2. Right-click the user and select Properties
   3. Cliquer sur l’onglet Account Click the Account tab
   4. Check the box Use DES encryption types for this account.
   5. Verify that no other option is checked
   6. Click OK
3. Click with the right mouse button on the user and re-enter their password weblogicsrv as it may have been corrupted by the change to encodying.

Accuracy: I use the account as login weblogicsrv weblogic itself may interfere with the internal login configured weblogic domain creation.

More documentation for setting up the SSO propose to nominate the user with the network name of the machine (in this case refers to serverweblo) however there could be confusion between the name of the Active directory user (CN = users) and the machine name (CN = computers). weblogicsrv name on it is totally neutral.

Step 2 – Creating a Kerberos SPN and generation of a file. Keytab (on serverad)

The SPN (Service Provider Name) is a Kerberos service name is defined in addition to the login created in step 1 in Active Directory because it is not compatible Kerberos.
The approach is to create a service name which can identify the service weblogic when a user wants to refer to the KDC. The Kerberos service name to be associated with the Active Directory user created in the previous step without which Kerberos can not make a link between the two entities.

The Kerberos service name (syn of SPN) that we will create is HTTP / serverweblo.sdaclin.fr.
HTTP representing the type of service, in this case an authentication request for a Web service. This name is not chosen at random, it is defined by weblogic when asked to kerberos token. IE devra donc trouver cette clef dans le domaine auquel il appartient. IE will have to find this key in the field to which it belongs.
The service name is fully qualified Kerberos HTTP / serverweblo.sdaclin.fr @ SDACLIN.FR. ATTENTION box is significant. The suffix with arobase represents the Kerberos Realm in which the SPN is declared.

Creating the link between the user and the AD that SPN weblogic process.

c: \ setspn.exe-A HTTP / serverweblo.sdaclin.fr weblogicsrv

Generating a keytab with ktab.exe [ktab.exe tool is available in the bin directory of a java JRE 1.4.2.]

C: \ program files \ j2re1.4.2_16 \ bin \> ktab-kc: \ weblogicsrv.keytab-a weblogicsrv@SDACLIN.FR

Enter the password weblogicsrv.

ATTENTION ktab not a native windows, you must specify a kerberos conf file in the c: \ winnt for ktab environmental kerberos knows where it will be used to generate the keytab file. -> See below: Configuring file krb5.ini to do so.

The keytab file is generated in c: \ (CAUTION must be sure you have the right to write in this folder first).

NB It is possible to avoid the use of setspn and ktab to use the tool that will ktpass in one command to create the spn and generate the keytab result, but I will not use this this documentation.

Step 3 – Configure weblogic server (on serverweblo)

keytab copy the file to the root of your domain weblogic

The file weblogicsrv.keytab product in step 2 must be copied to the server serverweblo in weblogic which will make use of.

The file is copied for example to the location: c: \ bea \ user_projects \ domain \ mykerberosdomain \ weblogicsrv.keytab

Configure the file krb5.ini

Create configuration file c: / winnt/krb5.ini

[libdefaults]
d default_realm = SDACLIN.FR
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc

ticket_lifetime = 600

[realms]
SDACLIN.FR = (
kdc = 192.168.1.2:88
admin_server = serverad
default_domain = SDACLIN.FR
)

[domain_realm]
sdaclin.fr = SDACLIN.FR

[appdefaults]
autologin = true
forward = true
forward = true
encrypt = true

NB: On the machine weblogic Win XP SP2, the winnt folder does not exist it was created in the “windows” exist.
NB: This file is created in / etc/krb5/krb5.conf on a Unix server (this path may vary depending on the distrib on RHEL it is / etc/krb5.conf).

Configuring the weblogic server

create the file in the root of your domain weblo (example: c: \ bea \ user_projects \ domain \ mykerberosdomain \ krb5Login.conf)

com.sun.security.jgss.initiate { com.sun.security.jgss.initiate (
com.sun.security.auth.module.Krb5LoginModule required com.sun.security.auth.module.Krb5LoginModule required
principal=”weblogicsrv@SDACLIN.FR” useKeyTab=true main = “weblogicsrv@SDACLIN.FR” useKeyTab = true
keyTab=weblogicsrv.keytab storeKey=true debug=true; keytab = weblogicsrv.keytab storeKey = true debug = true;
}; );

com.sun.security.jgss.accept { com.sun.security.jgss.accept (
com.sun.security.auth.module.Krb5LoginModule Required com.sun.security.auth.module.Krb5LoginModule Required
principal=” weblogicsrv@SDACLIN.FR” useKeyTab=true main = “weblogicsrv@SDACLIN.FR” useKeyTab = true
keyTab=weblogicsrv.keytab storeKey=true debug=true; keytab = weblogicsrv.keytab storeKey = true debug = true;
}; );

Modifier la commande de lancement du server startWeblogic.cmd qui se trouve à la racine de votre demaine en y ajoutant les paramètres suivantes : Modify the command to launch the server startWebLogic.cmd which is at the root of your tomorrow by adding the following parameters:

-Djava.security.auth.login.config=krb5Login.conf -Djava.security.auth.login.config = krb5Login.conf
-Djavax.security.auth.useSubjectCredsOnly=false -Djavax.security.auth.useSubjectCredsOnly = false
-Dweblogic.security.enableNegotiate=true -Dweblogic.security.enableNegotiate = true

Configurer le REALM weblogic Configuring the weblogic REALM

Start the server and modify the console in the weblogic REALM parameters as follows to configure identity assertion:

1. Open the Security -> Realms.
2. Choose the current realm.
3. Open the tree node Providers -> Authentication Providers.
4. On the “authenticator” click on “Configure a new Single Pass Identity assertion”.
5. Give a name and specify the option “Authorization” Chosen as Active Type and leave the option Base 64.
6. Click Apply to activate the changes.

Step 4 – Create a Test Application weblogic

Our servers serverweblo and serverad being in phase one another for the SSO, it only remains for us to develop a test application.

Web.xml

In it you need to add some security-constrained, which describes via a url-pattern elements to which access is restricted and the type of protection CLIENT-CERT, which refers to the client certificate not SSO.

<security-constraint>
<display-name> for SSO Security Constraint </ display-name>
<web-resource-collection>
<web-resource-name> Kerberos </ web-resource-name>
<description> Group of Users </ description>
<url-pattern> / * </ url-pattern>
</ web-resource-collection>
<auth-constraint>
<role-name> SSOrole </ role-name>
</ auth-constraint>
</ security-constraint>

<login-config>
<auth-method> CLIENT-CERT </ auth-method>
</ login-config>
<security-role>
<description> Role description </ description>
<role-name> SSOrole </ role-name>
</ security-role>

Weblogic.xml file

In this file we will make the mapping between a security role and a role of weblogic realm or principal (as username weblogic) or a group (always under weblogic user group).

In this case, we explicitly map the role with the user named weblogic “sdaclin. This user is obviously not by default but it is possible to create and fill through the console as a user defined in the LDAP integrated with weblogic.

<security-role-assignment>
<role-name> SSOrole </ role-name>
<principal-name> sdaclin </ principal-name>
</ security-role-assignment>

This second example closer to a reality matches the role with the role of the same name in the REALM using the externally-defined tag.Therefore SSOrole is a role defined in the console for your Realm.

<security-role-assignment>
<role-name> SSOrole </ role-name>
<externally-defined>
</ security-role-assignment>

A JSP test must then be created which shall include the following tag will display the name of the user logged in:

<% = request.getRemoteUser ()%>

For my part, I used a servlet that appealed to the principal (see the documentation JAAS) and whose code is as follows:

String intranauteName = request.getUserPrincipal().getName(); IntranauteName String = request.getUserPrincipal (). GetName ();

Support for BEA offers a sample application as a WAR to the following address:

https: / / support.bea.com / application_content / product_portlets / support_patterns / WLS / ssotestwebapp.zip

Troubleshooting

If despite all these explanations, you’re still having problems, here are some ways to debug it.

Checking the time unit of players SSO

The kerberos protocol takes into account the temporal integrity of everyone involved to ensure that one of the actors did not take the time to crack by brute force a ticket before sending. It is imperative to ascertain that all OS have the same hours.

Enabling debug mode in the weblogic server for SSO

Add in the server startup options to see the debug traces in the console as:

-DDebugSecurityAdjudicator = “true”
-Dweblogic.debug.DebugSecurityAtn = “true”
-Dsun.security.krb5.debug = true
-Dweblogic.StdoutDebugEnabled = true

Verify the proper establishment of the connection between the user and the SPN weblogicsrv

Serverad on the server perform the following command:

c: \-l setspn weblogicsrv

The result should look like this:

Registered servicePrincipalName weblogicsrv for CN =, CN = Users, DC = sdaclin, DC = fr:

HTTP / serverweblo.sdaclin.fr

Verifying the proper operation of the roster. Keytab

To verify the proper functioning of the keytab file, you can on the server serverweblo use the kinit.exe (a JVM in Java) by running (it should be heard before the temp copy of the test keytab file in the bin directory the JVM):

c: \ bea \ jdk142_11> kinit.exe-k-t weblogicsrv.keytab weblogicsrv@SDACLIN.FR

The following output should appear:

New ticket is stored in cache in file: c: \ Documents and [...]

If this is not the case, your keytab file does not work.

Checking client configuration IE

By default if no one has changed the security options of your client IE, it should allow the sending of kerberos ticket to all members of his domain. . As a result the client is IE in the same domain as the server serverweblo, everything will work natively.

However, a checklist is available to ensure proper configuration of IE to the following address:

http://edocs.bea.com/wls/docs81/secmanage/sso.html # 1101398

Verification of kerberos tickets stored on different players SSO

. Each Kerberos ticket can be cached more or less time on the various stakeholders in the SSO, it is recommended in case of problems downloading the application kerbtray.exe that allows you to view cached tickets but also to serve.

This tool is particularly useful to check the encoding of tickets cached in fact does not use the java native microsoft encryption RC4-HMAC, hence it must be ensured in case of problem tickets from the KDC are in a format compatible including-cbc-crc.

Primodial another point: the tickets are cached which means that if you do several tests you must purge the cache otherwise the tickets would not be reiterated and every effort would be unsuccessful.

Troubleshooting section of sun

This page tracks débuguage proposed by Kerberos sun.

http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/tutorials/Troubleshooting.html

Verification of network frames during the SSO

If despite all this you still can not obtain a functional SSO you only to run wireshark on the post EI and the server and see how weblo interlace frames and http requests to the KDC.

I recommend you use the following capture filter:

host (port 7001 or port 88)

This filter allows you to see the exchange HTTP (because weblo runs on port 7001) and exchange kerberos (because 88 is the default port of Kerberos).

References

Documentation officielle de la mise en place du SSO pour weblogic 8.1 : Official documentation of the implementation of the SSO for weblogic 8.1:

http://edocs.bea.com/wls/docs81/secmanage/sso.html http://edocs.bea.com/wls/docs81/secmanage/sso.html

Address of the web-app testing support provided by BEA to test an application to which access is protected by certificate

https: / / support.bea.com / application_content / product_portlets / support_patterns / WLS / ssotestwebapp.zip