AWI & SSO

[Michael A. Lowry]

I’m still trying to get single sign-on working. As a part of this, I would like to understand how SPNs and keytabs must be set up to enable SSO in the Automic Web Interface.

The documentation page on SSO set-up contains very little information on this topic:

SSO configuration for web applications

In order to implement Single Sign-on for web applications (such as Automic Web Interface orAutomic Release Automation), a keytab file with HTTP as Service Principal Name is required.

For example:

 

HTTP/winhost01.domain.sample

 

In this example, winhost01 is the host on which, for example, the Automic Web Interface (Tomcat) is installed.

The SPN name must also be entered in the variableUC_KDC_SETTINGSusing the "HTTP" key. If several AWI/ARA installations are available for an Automation Engine system, then other names separated by a semi colon can be added.

Example:

 

HTTP/winhost01.domain.sample;HTTP/winhost02.domain.sample

 

These instructions indicate that winhost01 and winhost02 are the servers where the AWI is hosted, but no instructions are provided for creating the keytab file containing the HTTP keys. It is not clear whether this keytab file should be the same one containing the AE service keys, or a separate keytab. It is not clear where the keytab(s) should be placed (on which server, and in which directory). The documentation page on configuring AWI login and user authentication does not answer these questions either.

Can anyone fill in the gaps?

[Michael A. Lowry]

Also, does the AWI have to run as a particular user? That is, must it run as the service user on which the HTTP SPN is defined?

[Michael A. Lowry]

To whomever changed this discussion to a question: thanks, but I actually prefer the discussion format. When one marks a post a question, one must answer for each response whether the response answers the question. Pop-up reminders appear continually until one does this. This is not desirable.

[Michael A. Lowry]

Another question:
Is it possible to enable SSO for both the Java User Interface and the Automic Web Interface?

[Michael A. Lowry]

With help from Automic Support & Development, I have finally made some progress on this. I documented my findings in my original discussion thread on this topic:
Single sign-on / integrated authentication

With the benefit of the new information provided by Automic, I can now answer some of the questions I posed earlier:

Q1. What keys should be in the keytab file?
A1. All keys should be in the same keytab file.

Q2. Does the keytab have to be installed on the AWI server?
A2. No. If the nodes running the AWI server are different from the nodes running the Automation Engine, then the keytab does not need to be installed on the AWI nodes. The keytab needs to be installed only on the nodes that run the Automation Engine. The full path to this file is specified in KEYTAB in UC_KDC_SETTINGS.

Q3. Must the AWI run as a particular user? (That is, must there be a relationship between the user that runs the AWI and the user associated with an AWI key in the keytab?)
A3. No. The AWI can run as any user.

Q4. Is it possible to enable SSO for both the Java User Interface and the Automic Web Interface at the same time?
A4. Yes.

[StéphaneCardin612316]

Hi, 

I confirm that it is possible to enable the SSO for both clients with the 11.2. 

However, after configuring the SSO for AWI I bumped into some issue : the token sent by the web browser was invalid for the jwp. 

While debugging the jwp with the flag 

-Dsun.security.krb5.debug=true -Dsun.security.spnego.debug=true -Djava.security.debug=gssloginconfig,configfile,configparser,logincontext

I found that the problem was in the spnego part 

SpNegoToken NegTokenInit: reading Mechanism Oid = 1.2.840.113554.1.2.2 SpNegoToken NegTokenInit: reading Mechanism Oid = 1.3.6.1.4.1.311.2.2.30 SpNegoToken NegTokenInit: reading Mechanism Oid = 1.3.6.1.4.1.311.2.2.10 SpNegoToken NegTokenInit: reading Mech Token SpNegoContext.acceptSecContext: received token of type = SPNEGO NegTokenInit SpNegoContext: negotiated mechanism = 1.2.840.113554.1.2.2 The underlying mechanism context has not been initialized SpNegoContext.acceptSecContext: mechanism wanted = 1.2.840.113554.1.2.2 SpNegoContext.acceptSecContext: negotiated result = ACCEPT_INCOMPLETE

Which lead me to this bug : https://bugs.openjdk.java.net/browse/JDK-8078439

With the jdk-8u111, the AWI SSO is now working flawlessly. 

Hope this helps. 

[StéphaneCardin612316]

More precisely, this bug is fixed with the jdk-8u51 (1.8.0_51-b16). 

Source : http://www.oracle.com/technetwork/java/javase/2col/8u51-bugfixes-2587594.html

[Michael A. Lowry]

Stéphane Cardin wrote:

More precisely, this bug is fixed with the jdk-8u51 (1.8.0_51-b16).
Source : http://www.oracle.com/technetwork/java/javase/2col/8u51-bugfixes-2587594.html

That explains why we haven’t seen this problem. We’re running 1.8.0_91.

The problem we now face is that whether SSO works seems to depend on the particular OS & browser. There are several failure modes:

1. The initial authentication with the KDC does not complete, and the login window displays
   
   Requesting Kerberos login indefinitely. Login with a password is also not possible.
   
2. The message Server connection lost, trying to reconnect... appears indefinitely. Login is not possible.
   
3. The initial authentication with the KDC completes successfully, but the login using SSO times out.
   

I am concentrating on #1 right now, because it seems to be the most common. I will report back here when I have made progress.

[Marcel Friedmann]

Dear Michael,
I am currently setting up Kerberos SSO authentication and I ran also in failure #1 and #2.
Did you find any reason / fix for that?

Thx
Marcel

[Michael A. Lowry]

Marcel Friedmann said:

Dear Michael,
I am currently setting up Kerberos SSO authentication and I ran also in failure #1 and #2.
Did you find any reason / fix for that?

See my other discussion thread on this topic:

Single sign-on / integrated authentication

[Marcel Friedmann]

i - checked it before but did not find any answer to this.  :(
However was able to pin down this to a "Bad Request" HTTP Response (400) sent by the Tomcat Server when the browser requested /awi/ssourl with the Kerberos ticket attached.

It seems that the tomcat default configuration cannot handle http headers larger then 8 KB.

This results in exceptions in catalina.out:
java.lang.IllegalArgumentException: Request header is too large 

Solution was to simply add the maxHttpHeaderSize parameter with a extended value to the connector defined in the server.xml.

[Michael A. Lowry]

Marcel Friedmann said:

It seems that the tomcat default configuration cannot handle http headers larger then 8 KB.

This results in exceptions in catalina.out:
java.lang.IllegalArgumentException: Request header is too large 

Solution was to simply add the maxHttpHeaderSize parameter with a extended value to the connector defined in the server.xml.

Yup, we ran into that too. It started when we enabled SSO, likely because the (rather large) Kerberos session key is included in the HTTP headers.