In this blogpost I will explain how you can use the OWSM ( Oracle Web Service Manager) Kerberos policies in Fusion Middleware 11g. Some of these kerberos policies are compatible with the Window Active Directory KDC and these kerberos tokens can be used for authentication and message protection. It basically works the same as I described in my blog about
Windows Single Sign On with web applications deployed on WebLogic. If you want to use OWSM SAML policies instead then you can use
this blogpost and for username tokens or certificates protection you can use
this blogpost.
OWSM support the following Kerberos server policies.
- oracle/wss11_kerberos_token_service_policy, this can be used for authentication just like the username token policies. It does not encrypt the message and can be used with AD and MIT
- oracle/wss11_kerberos_token_with_message_protection_basic128_service_policy, besides the authentication it also encrypts the message. This policy works with AD.
- oracle/wss11_kerberos_token_with_message_protection_service_policy, this policy does the same but only works with MIT.
For Windows AD we can only use the first two policies.
Before we can start you need to know or do the following
Know the supported encryption types of your Windows Environment. For example Windows XP or Windows 2003 Domain Controller ( not SP1 ) does not support every encryption type.
I got this working with a Windows 7 client and a Windows 2008 R2 Domain Controller and my encryption type is
RC4-HMAC-NT, which is also supported in Java 1.6
My Active Directory domain = ALFA.LOCAL ( always use it in uppercase )
Make sure that all server can be found in the DNS ( and reverse ) and that the time is synchronized on all machines.
In my test environment I will use 3 servers, The first is my AD 2008 server, second is the OWSM server called soaps3.alfa.local on which we will deploy a kerberos protected JAX-WS service and third is the Web Service Proxy client machine called win7.alfa.local and this has the OWSM kerberos client policy.
We need to create 2 unique service account in Active Directory. In this case
soaps3_kerb and
win7_kerb and make sure that the passwords of these accounts never expires.
On the Windows 2008 DC server I did the following to generate a service account called HTTP/soaps3.alfa.local and map this to soaps3_kerb AD account. Soaps3 is the server hostname of the WebLogic Server.
First generate a keytab file for the HTTP/soaps3.alfa.local@ALFA.LOCAL account, HTTP is a container ( IIS also uses this convention ) and ALFA.LOCAL is my AD domain.
ktpass -princ HTTP/soaps3.alfa.local@ALFA.LOCAL -pass Welcome01 -mapuser soaps3_kerb@ALFA.LOCAL -out c:\soaps3.keytab -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT
copy the generated soaps3.keytab file to the WebLogic machine ( soaps3 )
I put it in the c:\oracle folder.
Now we need to modify the Service Principal Names with the SPN utility ( Do this on the AD server )
setSpn -A HTTP/soaps3.alfa.local@ALFA.LOCAL soaps3_kerb
Now we can do the same for the win7 machine, which will be used as ws client.
ktpass -princ HTTP/win7.alfa.local@ALFA.LOCAL -pass Welcome01 -mapuser win7_kerb@ALFA.LOCAL -out c:\win7.keytab -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT
copy the win7.keytab to the oracle folder of the win7 machine
setSpn -A HTTP/win7.alfa.local win7_kerb
On the win7 and soapss3 machine we need to create krb5.ini textfile and put this in c:\windows
ALFA.LOCAL is my AD domain and soaps3 is my WebLogic server and it exists in the alfa.local dns domain.
ad-win2008r2.alfa.local is my domain controller.
the krb5.ini for the soaps3 machine
-------------------
[libdefaults]
default_realm = ALFA.LOCAL
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
permitted_enctypes = rc4-hmac
[domain_realm]
.soaps3.alfa.local = ALFA.LOCAL
soaps3.alfa.local = ALFA.LOCAL
[realms]
ALFA.LOCAL = {
kdc = ad-win2008r2.alfa.local
admin_server = ad-win2008r2.alfa.local
default_domain = alfa.local
}
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true
---------------
and the win7 machine version.
-----------------
[libdefaults]
default_realm = ALFA.LOCAL
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
permitted_enctypes = rc4-hmac
[domain_realm]
.win7.alfa.local = ALFA.LOCAL
win7.alfa.local = ALFA.LOCAL
[realms]
ALFA.LOCAL = {
kdc = ad-win2008r2.alfa.local
admin_server = ad-win2008r2.alfa.local
default_domain = alfa.local
}
------------------
Go to the JVM bin folder of the the WebLogic server. This is the soaps3 machine. Here we generate a token.
cd c:\oracle\jrockit-jdk1.6.0_26-R28\bin
kinit HTTP/soaps3.alfa.local@ALFA.LOCAL
Provide the password of HTTP/soaps3.alfa.local and the ticket will be stored in your user profile.
Do the same on the win7 machine but then with the use HTTP/win7.alfa.local account.
cd c:\oracle\jrockit-jdk1.6.0_26-R28\bin
kinit HTTP/win7.alfa.local@ALFA.LOCAL
That's all for the kerberos configuration on the windows machines. Now we need to do some configuration in the Enterprise Manager and the WebLogic Console.
First we need to configure the kerberos Login module.
Go the Enterprise Manager (EM) application of the WebLogic server. Open the WebLogic Domain treenode and select your WebLogic domain. In the Domain menu (right window) go to Security -> Security Provider Configuration
Select the krb5.loginmodule and click on the Edit button.
Here we need to provide the principal name HTTP/soaps3.alfa.local@ALFA.LOCAL and its keyTab file.
Save and restart the WebLogic server.
After that we need to create a user on the WebLogic domain or configure an AD ldap authenticator.
The user HTTP/win7.alfa.local must exists on the domain. The password does not matter because it is already authenticated against the AD.
For the server side you can enable the kerberos debugging by adding the following parameter to the EXTRA_JAVA_PROPERTIES parameter in the setDomainEnv.bat of your domain. -Dsun.security.krb5.debug=true
Deploy the following JAX-WS service on the soaps3 server.
That's all for the server part, now we can test the web service proxy client on the win7 machine.
On the client you can also set the following project options -Dsun.security.krb5.debug=true to see all the debug information. And off course you can use the HTTP analyzer to see all the traffic.
This is my test client code.
When you run the test client you should be authenticated and see the output.
