In this article, I’ll tell you how we switched from NTLM to Kerberos authorization for applications on the Oracle Weblogic Server, thereby making it easier for users to log in, removing the need to enter a password. All users, as well as the application server, are in the same domain, and domain authorization for Weblogic server applications was previously configured. All configurations were tested on WLS 12.1.2.
First, a little theory, very briefly for further understanding of the process of interaction.
What is Single Sign-On?
Single sign-on (SSO) is the mechanism by which a single user authentication activity allows a user to access all computers and systems where he has permission to access, without having to enter multiple passwords. Previously entered credentials will be transparently reused by various components.
What is Kerberos?
Kerberos is a network authentication protocol that was first developed by the Massachusetts Institute of Technology. Kerberos is a secure method for authenticating a request for a service on a network and is designed to provide strong authentication for client-server applications using cryptography with a secret key.
What is SPNEGO?
SPNEGO is a simple and secure GSSAPI negotiation mechanism. This is a standardized interface for authentication (for example, JNDI for directory searches), the default implementation for SPNEGO for Windows is Kerberos (for example, LDAP for JNDI). Microsoft terminology uses the Windows Integrated Authentication as a synonym for SPNEGO. In Windows Integrated Authentication, Kerberos or NTLM protocols can be negotiated.
When the server receives a request from the Internet Explorer browser (IE 6.1 or higher), it can request that the browser use the SPNEGO protocol for authentication. This protocol performs Kerberos authentication over HTTP and allows Internet Explorer to delegate privileges so that the web application can log in to subsequent Kerberized services on behalf of the user.
When the HTTP server wants to run SPNEGO, it returns a “401 Unauthorized” response to an HTTP request with the header “WWW-Authorization: Negotiate”. Internet Explorer then contacts the ticket-granting service (TGS) to get the ticket. He chooses the special name of the service member to request a ticket, for example:
HTTP/webserver@<DOMAIN NAME>
The returned ticket is then wrapped in an SPNEGO token, which is encoded and sent back to the server using an HTTP request. The marker unfolds and the ticket is authenticated.
Kerberos Benefits
Using kerberos allows administrators to disable NTLM authentication as soon as all network clients are able to authenticate Kerberos. Kerberos is more flexible and efficient than NTLM and more secure.
Kerberos-based SSO configuration in a Weblogic application server environment
Interaction scheme:
- When a registered user (PC) requests a resource from Oracle WebLogic Server (WLS), it sends the original HTTP GET request.
- The Oracle WebLogic Server (WLS), which executes the SPNEGO token handler code, requires authentication and returns 401 Access Denied, WWWAuthenticate: Negotiate.
- The client (PC Browser) requests a session ticket from the TGS / KDC (AD).
- The TGS / KDC (AD) provides the client with the required Kerberos ticket (provided that the client is authorized) wrapped in a SPNEGO token.
- The client re-sends the HTTP request GET + token Negotiate SPNEGO in the authorization header: Negotiate base64 (token).
- Verifying the SPNEGO Web Authentication on the Weblogic server sees the HTTP header with the SPNEGO token. SPNEGO checks the SPNEGO token and receives user information.
- After Weblogic receives user information, it checks the user in Microsoft Active Directory / KDC. When the authentication process is done, Weblogic executes the corresponding Java code (servlets, JSP, EJB, etc.) and checks for authorization.
- The Oracle WebLogic Server Token Handler handler code accepts and processes the token through the GSS API, authenticates the user, and responds with the requested URL.
We now turn to practice
1. Perform settings on the server side of the domain controller, on which the TGS / KDC services are configured.
- Create a user in Active Directory (password validity should not be limited)
- Set the appropriate SPN for the WLS server name
Perform the check set by SPN
setspn –l HTTP_weblogic
should return two entries
Generate keytab file
ktpass -princ HTTP_weblogic@mycompany.com -pass PASSWORD -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -kvno 0 -out c:\krb5.keytab
Copy this file to WLS server
2. Configure the WLS server
- You need to create a krb5.ini file in the% windir%: C: \ Windows folder. This file contains configuration parameters for clients, for example, where the KDC is located. The file will look like this:
[libdefaults] default_realm = <DOMAIN NAME> ticket_lifetime = 600 [realms] <DOMAIN NAME> = { kdc = <HOSTNAME OF AD/KDC> admin_server = <HOSTNAME OF AD/KDC> default_domain = <DOMAIN NAME> } [domain_realm] . <DOMAIN NAME>= <DOMAIN NAME> [appdefaults] autologin = true forward = true forwardable = true encrypt = true
- Create a configuration file krb5Login.conf:
com.sun.security.jgss.krb5.initiate { com.sun.security.auth.module.Krb5LoginModule required principal="user@MYCOMPANY.COM" useKeyTab=true keyTab=krb5.keytab storeKey=true debug=true; }; com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule required principal="user@MYCOMPANY.COM" useKeyTab=true keyTab=krb5.keytab storeKey=true debug=true; };
Please note that the domain name must be in
upper case . For earlier versions, use com.sun.security.jgss.initiate in the previous config instead of com.sun.security.jgss.krb5.initiate.
- Both the krb5Login.conf and krb5.keytab files must be located in the root directory of the WLS domain of the server.
- Editing the setDomainEnv file
Find the line set JAVA_OPTIONS =% JAVA_OPTIONS% and at the end add
-Djava.security.auth.login.config=< >\krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true
- In this case, we do not consider the WLS authorization setting in AD. We believe that it works, if you need to paint this item in the comments.
- Configuring SPNEGO in WLS
To do this, go to the WebLogic Server Administration Console
Go to the Security Realms> myrealm> Providers section and click the Add button.
Choose the type of “WebLogic Negotiate Identity Assertion provider”
Check that both parameters would be selected.
Press the Reorder button and control the arrows set the sequence of authorization types. WebLogic Negotiate Identity Assertion provider should be installed in the first place in the second place Provider that performs LDAP authentication (domain authorization)
- Next, you need to specify the application CLIENT-CERT authorization method, these changes are applied in the application's web.xml file
<security-constraint> <display-name>Security Constraint for SSO </display-name> <web-resource-collection> <web-resource-name>My webapp</web-resource-name> <description>Group of Users</description> <url-pattern>/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> <security-role> <description>Role description</description> <role-name>valid-users</role-name> </security-role>
The role must be pre-installed on the system. In our case, the built-in role for ADF (valid-users) is used, and then further on the basis of domain groups are distributed powers.
To identify problems with authorization, you must enable debug. To do this, go to the section.
Environment -> Servers choose our server -> Debug -> weblogic (deploy) -> Security -> atn, set checkmarks and enable.
To enable and disable debug, no reboot is required.
Login to the domain machine, click on the application link and log in without entering a password. It is worth noting that the Exit button in the application will not work in this configuration.