Documentum REST - Kerberos SSO

We are trying to configure SSO using Kerberos in Documentum REST 7.3 and have followed the steps listed in the REST 7.3 Development Guide. In order to validate whether SSO is working or not, I am referring to the below excerpt from the Dev guide

Docs.JPG.jpg

As mentioned in Step1, I am calling a URL http://myserver/dctm-rest/repositories/myrepo/currentuser.xml using a REST client. This gives me a ‘401 Unauthorized’ along with ‘WWW-Authenticate: Negotiate’, as mentioned in Step 2. This is how the response from Step1 looks like -

Headers.JPG.jpg

Now, in Step3, the ask is to call the same URL again with Authorization as Negotiate and some token. My question is how to get this token that needs to be passed as part of Authorization Header? Is this something that is expected to be returned in the Step1 response?

Regards

Anshul

Find more posts tagged with

Documentum

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

abc123

This licensing issue may be caused by a defect recently found in the 3rd party library Quest, when running on specific JRE versions. Please contact our support to get a patch fix.

All comments

abc123

If your test is in a Windows domain machine, and you are logged in as a domain user, you can use Internet Explorer to test the same URL. Please follow this guide to configure your IE, https://techsupport.osisoft.com/Troubleshooting/KB/KB01223.

AnshulK

Thanks William.

We do have Windows domain machine and logged in as domain user. I have followed the steps in the article you have posted.

Once I fire the GET request, I get a response with WWW-Authenticate as Negotiate and 401 Unauthorized (same as in the screenshot above). So, everything is good till Step 2. Now, Step 3 in the documentation says


GET /${resource-url} HTTP/1.1
Authorization: Negotiate YIIZG1hZG1pbjpwYXNzd29yZ

I am not able to make out from where to get the token referred to as 'YIIZG1hZG1pbjpwYXNzd29yZ'? Should this be received from the server in Step2 or is there another way to get this token?

abc123

Hi Anshul, the error response of step 2 (401 + WWW-Authenticate: Negotiate) triggers the IE to enable windows login for the request URL (either NTLM or Kerberos). In Step 3, your IE will automatically negotiates a Kerberos ticket from the domain controller (using its local TGT) and sends Kerberos ticket (i.e. Negotiate YIIZG...) to the REST server.

If the Kerberos has been setup correctly, you won't perceive step 2~3 in your IE because the negotiation occurs under the neath (but you can observe these steps by DEBUG logs on REST server side).

If the Kerberos hasn't been setup correctly, your IE will promote the login dialog and ask you to input credentials repeatedly. But it won't succeed.

The reasons for Kerberos failure could be many causes. But firstly you need to check:

Assumed your REST server is web.acme.com
You must create a SPN as HTTP/web.acme.com, meaning that the hostname must match
Your REST request must use the right scheme and host name, i.e. http://web.acme.com:8080/dctm-rest/...

Only when the SPN is created correctly and the request URL matches, the IE can recognize your target resource as a Kerberos service, so that a Kerberos ticket is requested from the domain controller.

AnshulK

Hi William,

Thank you very much for the detailed steps.

I have verified that SPN is created with correct host name. Also, the REST request has the correct scheme and host name.

But still when I hit the URL in IE11, I get a login dialog and it keeps on coming back even after entering correct credentials.

In order to debug this we added the following debug parameters

- rest-api-runtime.properties

--rest.message.logging.enabled=true

- dctm-rest\WEB-INF\classes\log4j.properties

--com.emc.documentum.rest=DEBUG

Now, when I hit the URL, it shows the below errors in rest-api.log. Any idea what could be going wrong here?




Caused by: javax.security.auth.login.LoginException: com.dstc.security.util.licensing.InvalidLicense: Error verifying license: Invalid encoding for signature
  at com.dstc.security.util.licensing.LicenseValidator.verifyLicense(LicenseValidator.java:167)
  at com.dstc.security.util.licensing.LicenseValidator.checkAndCache(LicenseValidator.java:294)
  at com.dstc.security.util.licensing.LicenseValidator.check(LicenseValidator.java:316)
  at com.dstc.security.kerberos.Licensed.<clinit>(Licensed.java:60)
  at com.dstc.security.kerberos.Kerberos.<clinit>(Kerberos.java:1994)
  at com.dstc.security.kerberos.jaas.KerberosLoginModule.getEncryptionTypes(KerberosLoginModule.java:1533)
  at com.dstc.security.kerberos.jaas.KerberosLoginModule.getKerberos(KerberosLoginModule.java:1494)
  at com.dstc.security.kerberos.jaas.KerberosLoginModule.loadTGT(KerberosLoginModule.java:1592)
  at com.dstc.security.kerberos.jaas.KerberosLoginModule.getTGT(KerberosLoginModule.java:1556)
  at com.dstc.security.kerberos.jaas.KerberosLoginModule.login(KerberosLoginModule.java:454)

abc123

This licensing issue may be caused by a defect recently found in the 3rd party library Quest, when running on specific JRE versions. Please contact our support to get a patch fix.