Home Documentum

Documentum REST - Kerberos SSO

edited August 7, 2017 in Documentum

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


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 -


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?



Best Answer

  • edited August 7, 2017 Accepted Answer

    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.


  • edited July 27, 2017

    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.

  • edited July 27, 2017

    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?

  • edited July 27, 2017

    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:

    1. Assumed your REST server is web.acme.com
    2. You must create a SPN as HTTP/web.acme.com, meaning that the hostname must match
    3. 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.

  • edited August 1, 2017

    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


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


    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)
  • edited August 7, 2017 Accepted Answer

    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.

Sign In or Register to comment.