Adelia SSO allows direct authentication in the middleware of a Windows user logged in to an domain via Kerberos authentication in the Active Directory.
Adelia SSO provides the following features:
- Transparent connection of a Windows client to a Windows, AS/400 or Java middleware server using the Windows user's credentials (without profile/password configuration for the Middleware).
- Transparent connection via a Web browser supporting SSO (SPNEGO) to an Adelia Cloud application, with delegation of credentials to the Adelia Middleware if possible.
- With the Windows daemon, the MWSERVER.EXE process can be started with the client profile credentials.
The Middleware also supports mixed mode for connections (some connections can be completed without passwords while others explicitly provide credentials).
The client and server must be at least version 14 PTF05 and the daemon must be configured to authorize single sign-on (configuration of MWSERVER.INI file or MWAUTH DTAARA).
The client configuration file must reference the *SSO pseudo-profile in the client configuration of physical servers to initiate single sign-on (MWCLIENT.INI file configuration).
Active Directory configuration for the Adelia daemon
The operating principle is to create a dedicated user at domain level to run Middleware services in the Windows domain. Middleware services must be started with this profile (in the example: mwdaemon@domain.com).
The Kerberos principals associated with the Adelia daemon need to be associated with this user. By default, the Adelia middleware identifies itself with the service principal MWDAEMON/host.domain.com, where host.domain.com is the qualified name of the machine on which the service is run.
For example, the following commands are used to create the "mwdaemon" user, associate the SPN with it, and create the key file for the Java daemon (krb5.keytab):
|
AS/400 server configuration
The AS/400 server must be configured to enable Single Sign-On (Enterprise Identity Manager configuration). AS/400 server configuration is outside the scope of this document.
See IBM documentation for further information. ↑ Top of page
AS/400 Middleware daemon configuration
If present, the MWAUTH DTAARA is used to indicate the authentication parameters. If it is not present, the daemon starts in standard mode (authentication by user/password).
Windows Middleware daemon configuration
The Windows daemon uses the SPN MWDAEMON/host.domain.com by default, where host.domain.com is the qualified name of the machine on which the service is run. The SPN to use can be specified in the command line and the "-principal SPN" parameter of the daemon.
The "-asuser" parameter of the daemon enables the launch of MWSERVER processes with the client user permissions. The user must have permission to open a session on the server.
Java Middleware daemon configuration
The Windows daemon uses the SPN MWDAEMON/host.domain.com by default, where host.domain.com is the qualified name of the machine on which the service is run. The SPN to use can be specified in the command line and the "com.hardis.adelia.security.kerberos.principal" property ("-Dcom.hardis.adelia.security.kerberos.principal=SPN" parameter of the Java command starting the daemon).
The Java daemon uses the keytab to authenticate the server. The "krb5.keytab" file must be present in the private directory of the user starting the daemon. Another file can be used but a configuration file needs to be added (jaas.conf).
You can retrieve the file generated on the AD server using the KTPASS command, or create the key using the Java "ktab" command. You need to specify the password of the user associated with the SPN.
For example:
|
In Windows, if the server is part of a domain, the "krb5.ini" or "jaas.conf" file does not need to be provided. The default JVM configuration authenticates users in the Windows domain. ↑ Top of page
Adelia Cloud application configuration
The Java EE security extension helps the Pac4J Kerberos module to implement authentication via SPNEGO. The client workstation browser must be configured to enable SPNEGO for the application.
For SSO to be full (the user logged in to the system logs in to the Adelia Cloud application and the Adelia Cloud application connects to the Middleware without presenting a password), the browser must be configured to authorize Kerberos delegation of credentials. This enables the Web application to obtain a Kerberos "granting ticket" and present the credentials to the Middleware server in a transparent way.
Internet Explorer and Microsoft Edge configuration
You need to add the site to the list of trusted sites in the "Local intranet" security zone. To do this, open the control panel then "Internet options", select the "Security" tab and the "Local intranet" zone then click on "Sites".
Specify your server then click "Add".
You also need to enable integrated Windows authentication in the "Advanced" panel, in the "Security" section.
Chrome browser configuration
Chrome enables SPNEGO to be configured via two values in the "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome" registry key:
AuthServerWhitelist | This key indicates the servers on which authentication is enabled. It is a list of host names separated by commas and using generic characters. For example: |
AuthNegotiateDelegateWhitelist | This key indicates the servers which need to support the delegation of credentials (Middleware SSO). For example: *.domain.com |
If these keys are not configured, Chrome can also use the Internet Explorer network configuration options.
>> https://www.chromium.org/developers/design-documents/http-authentication
N.B. Chrome uses the Internet Explorer parameters if these are configured. However, in this case, delegation does not seem to work.
Firefox configuration
Firefox is configured via the "about:config" panel:
network.negotiate-auth.trusted-uris | This key indicates the servers on which authentication is enabled. It is a list of host name suffixes separated by commas and using generic characters. For example: .domain.com |
network.negotiate-auth.delegation-uris | This key indicates the servers which need to support the delegation of credentials (Middleware SSO). For example: .domain.com |
Active Directory configuration for the JEE application server
You need to create a profile and SPN for the HTTP server.
By convention, an HTTP server identifies itself with the service principal HTTP/host.domain.com where host.domain.com is the qualified name of the machine on which the service is run.
For example, the following commands are used to create the "tomcat" user, associate the SPN with it, and create the key file (keytab) for the Web server (DOMAIN.COM domain):
DSADD user "cn=tomcat,cn=users,dc=DOMAIN,dc=COM" -pwd password -display KTPASS -MAPUSER tomcat -PRINC HTTP/host.domain.com@DOMAIN.COM -PASS password -mapop set -ptype KRB5_NT_PRINCIPAL -out krb5.keytab |
Note that if you want an SSO at Middleware level, the profile starting the TOMCAT service must also authorize delegation of credentials.
SSO configuration in the Web application
To enable SSO, you need to use the Kerberos module of the Java EE security extension.
JEE application server configuration
No specific configuration is required at application server level.
When the Adelia Cloud application is unloaded or reloaded, if the web sessions persist, the Kerberos credentials are not saved. For Adelia SSO, this means that the Middleware SSO will no longer work.
Workaround: force the creation of a new JEE session by opening a new browser instance.
We recommend disabling session persistence at Web server level as it is meaningless for an Adelia Cloud application. For TOMCAT, this is done by adding the <Manager pathname="" /> directive to the application context.