Saturday Feb 04, 2012

Oracle Enterprise Gateway As Kerberos Service

This article explains how to configure OEG as Kerberos Service for authenticating requests using SPNEGO tokens.

For the purpose of this article, I will demonstrate a use case that involves the following 3 machines:

DC-SERVER.WINDC.DEMO.ORACLE.COM (Windows 2008 Server R2)
This server is the Active Directory Domain Controller and also acts as the Kerberos KDC.
The name of the domain is WINDC.DEMO.ORACLE.COM.

OEG-SERVER.ORACLE.COM (Windows 2008 Server R2)
This server hosts the Oracle Enterprise Gateway (version 11.1.1.6)
This server runs standalone, and is NOT part of the Windows Domain WINDC.DEMO.ORACLE.COM.

WIN7-CLIENT.WINDC.DEMO.ORACLE.COM (Windows 7)
This is a Windows 7 machine that is client to the Domain Controller DC-SERVER.WINDC.DEMO.ORACLE.COM.
Any user defined in Active Directory can log into this machine to the domain WINDC.
For the purpose of this demo, there are two user (DemoUser1 and DemoUser2) created in Active Directory that can log into WIN7-CLIENT.

How to configure a Windows Domain Controller and How to add a Windows client to the Domain?
If you are planning to create this setup using local VMs, here's an excellent guide (Youtube video) to configuring a Windows Domain Controller, and adding a Windows client to the Domain: http://www.youtube.com/watch?v=M4rjlD_Mx0w
In the context of this Blog post, the video can help setting up the Domain Controller on 
DC-SERVER.WINDC.DEMO.ORACLE.COM, and adding WIN7-CLIENT.WINDC.DEMO.ORACLE.COM to the Domain. 

This article will demonstrate that requests coming from WIN7-CLIENT (either via Web Browser or a Web Service client) that will call an end point defined/registered on OEG (running on OEG-SERVER) will be successfully authenticated by OEG Kerberos Service.
The credentials used to authenticate the user will be the Windows credentials of the user logged into the machine.
Note: The requests could come from any machine so long as it is a client to the Domain Controller.

The Screen shot below shows the users DemoUser1, DemoUser2 created in Active Directory on DC-SERVER.

Now begins the Kerberos Configuration....

Step 1 is to create a user account in Active Directory for OEG-SERVER.

The below screenshots show a user named OEG-SERVER created in Active Directory on DC-SERVER.

Step 2 is to create a Service Principal Name (SPN) on the Domain Controller (DC-SERVER) for OEG-SERVER

Run the following command to create the SPN that is mapped to the user account OEG-SERVER.

ktpass -princ HTTP/OEG-SERVER.ORACLE.COM@WINDC.DEMO.ORACLE.COM -pType KRB5_NT_PRINCIPAL -mapuser OEG-SERVER -pass Password1 -out c:\temp\oeg-server.keytab -crypto RC4-HMAC-NT -kvno 0

NOTE: The password in the above command must be the same as the password for the user account OEG-SERVER in Active Directory.

The below screenshot shows the command and its output.

The above command will output a keytab file (c:\temp\oeg-server.keytab).

Copy this keytab file inside some folder on OEG-SERVER.

Once the SPN is successfully created, you will notice the change in User Logon Name for the user OEG-SERVER. (see the screenshot below)

Now let’s begin the configuration in OEG...

Launch the Policy Studio, and under “External Connections”, right-click on “Kerberos Principals” and create a new Kerberos Principal. (Screenshot below)

Now, under “External Connections”, right-click on “Kerberos Services” and create a new Kerberos Service. (Screenshot below)
Click on the “Load Keytab” button to load the keytab file that was copied from DC-SERVER.

Now, let’s create a Kerberos Authentication Policy...

Create a new Policy (let’s name the policy “Kerberos Authentication”) and drag the “Kerberos Service” filter, and configure it as shown below.
Select “SPNEGO over HTTP” as the Kerberos standard. Leave all the other tabs with default configuration.

Add a “set message” and “reflect message” filter to complete the circuit. (see screenshots below)

Now, create a relative path “/kerberosauth” under “Default Services” (port: 8080), and make it point to the Policy created above.

Now, create a file called “krb5.ini” and configure it as shown below.
Copy the krb5.ini file inside C:\Windows on OEG-SERVER.

Please note that if you are using OEG 11.1.1.5, you need not create the krb5.ini file. You can do this configuration in the krb5.conf file inside OEG.

Finally, Deploy the configuration in the Gateway.

Now, we are almost ready to run the test case from a web browser running on WIN7-CLIENT, but first we need to configure some settings in the Browsers:

Firefox Settings:

Enter “about:config” in the address bar and hit enter, and then click on the “I’ll be careful, I promise” button.
Right-click on the preference name “network.negotiate-auth.trusted-uris” and select “modify”, and add the following URL: “http://oeg-server.oracle.com”

Note: You may also need to add an entry for OEG-SERVER.ORACLE.COM inside the “hosts” file on WIN7-CLIENT.

Finally, enter the URL: http://oeg-server.oracle.com:8080/kerberosauth, and hit enter.
Note: The user should NOT be prompted to enter username/password. The underlying Windows credentials of the user logged into the machine will be used for authentication.

In the example screenshot below, DemoUser1 is logged into WIN7-CLIENT, and hence you see this message.

Internet Explorer Settings:

  • Under Tools > Internet Options > Advanced, make sure the option “Enable Integrated Windows Authentication” is selected.
  • Under Tools > Internet Options > Security > Local Intranet > Advanced, Add this URL: “http://oeg-server.oracle.com”
  • Under Tools > Internet Options > Security > Local Intranet > Custom Level, Make sure that under “User Authentication > Logon, the option “Automatic Logon only in Intranet Zone is selected.

You may need to restart I.E.

Finally, enter the URL: http://oeg-server.oracle.com:8080/kerberosauth, and hit enter.
Note: The user should NOT be prompted to enter username/password.
In the example screenshot below, DemoUser2 is logged into WIN7-CLIENT, and hence you see this message.

DNS:

When a browser acquires a service ticket from the KDC, it presents a service principal name (SPN) for the service that it wants to connect to. This SPN is computed from the host name in the URL entered into the browser. For example if the user enters http://oeg-server.oracle.com:8080/kerberosauth, the SPN that the browser passes to the KDC in order to acquire a service ticket is HTTP/oeg-server.oracle.com@WINDC.DEMO.ORACLE.COM.

If the host name is defined in the DNS as “A-name” or host, the SPN is directly resolved from the host. For example:
On the DNS server, the following DNS record is defined:

HOST(A): oeg-server.oracle.com
On the client browser, the following URL is entered:
URL: http://oeg-server.oracle.com:8080/kerberosauth

The requested SPN is:
HTTP/oeg-server.oracle.com

Kerberos Authentication for Web Services

To configure Kerberos Authentication for web services, just plug in the “Kerberos Authentication” policy created above (minus the “Set Message” and “Reflect” filters) under the “Message Interception Points” > “Request From Client” > “Before Operation-specific Policy” tab in the Service Handler for the registered Web Service – just the same way you would intercept with a HTTP authentication policy.

Note: The WSDL url used by the web services client must contain the fully qualified name of the gateway server so that it matches the SPN.

About

Prasad works with customers across North America in implementing Security and Fusion Middleware solutions.

Search

Categories
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today