Is there some way to handle OTDS authentication with API REST and SAML assertion?
Hi all,
I have a portal that login users with ADFS and SAML. After the authenitcation the user should be authorized to use the API REST of Content Server.
I have configured OTDS to use SAML 2.0 Authentication Handler and it works when I login user from OTDS login.
Now I would use the Content Server API REST but I don't figure out how can I obtain an OTCS ticket.
First I thought to use a SAML Bearer OAuth2 flow as described in https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-08 but I don't find any documentation about it so I suppose that this standard is not supported.
Looking at OTDS API REST I see the endpoint /authentication/token
and I'm trying with it but I don't understand how to use it. I suppose to have to put some SAML assertions in the tokenBinary property.
POST /authentication/token Content-Type: application/json { "tokenBinary": "base64 saml assertions here?" }
Is it correct? And if so, how can I retrieve the SAML assertion I have to use?
Comments
-
You are on the right track and for anyone else's referenced I've covered this in a video KB here:
https://knowledge.opentext.com/knowledge/cs.dll/kcs/kbarticle/view/KB4242339
As for the SAML assertion you would need to make a separate call to your IdP to authenticate there first and then use the resulting encoded assertion in OTDS.
Jamie Pepper
Sr Technical Analyst
OpenText0 -
Hi JPepper,
I am trying to integrate OTCS 16.2 and my Java web application using REST and both have been setup to use OKTA (SAML 2.0) for authentication. I have followed the instructions provide in the link above.
I post the SAML response to the OTDS REST endpoint.
http://[SERVER]/otdsws/rest/authentication/tokenAnd this is the response from the OTDS server
{
"status": -805306355,
"error": "INVALID_CREDENTIALS",
"errorDetails": null
}I am able to use OKTA to login to my application as well as OTCS. But am unable to use the SAML response to get a ticket to call REST APIs on OTCS from my app.
What am I doing wrong here?
0 -
@sandeepvk1234 If you set your OTDS log level to debug under System Config in the admin UI you should be able to see the assertion coming through for your normal requests and for this REST API request. My guess is that the user we are decoding from the assertion does not exist in OTDS but if that user is you and the same user you use via the OTDS Web UI or via OTCS that shouldn't be occurring.
Please also note that that endpoint is protected so when calling it using something like PostMan and not our Swagger interface you would need to pass an OTDSTicket value in the header from a previously authenticated user to be able to use the API endpoint.
Jamie Pepper
Sr Technical Analyst
OpenText1 -
Hi JPepper,
Thank you. I am able to use the SAML assertion to get the OTDSTICKET now. It was a missconfiguration on my part on OTDS.
0 -
Hi Jamie,
This does not seem to work with OTDS 20.x. Our dev server is on OTDS version 16.6.2 and it works fine. But in the production running OTDS 20.x it fails. The following is the relevant lines from otds.log file. There are multiple OKTA configurations. OKTA1 is the one for the application that I am integrating with. The Config with name OKTA is for using OKTA with content server and that works perfectly fine. Our application that make the call to get the
NegotiateTokenAuthenticationHandler||Error processing token
OtdsAuthenticationManager||Authentication attempt for username [token] with handler token.negotiate result {FAILURE, INVALID_CREDENTIALS, null, null}
SAML2Handler||Error processing SAML Assertion as a token: java.lang.Exception: No valid SubjectConfirmationData Recipient found
SAML2Handler||PD94.....<SAML ASSERTION>
OtdsAuthenticationManager||Authentication attempt for username [token] with handler OKTA result {FAILURE, null, null, null}
OtdsAuthenticationManager||Authentication attempt for username [token] with handler OKTA1 result {FAILURE, null, null, null}
OTDSExceptionMapper||Error from REST API for [POST /otdsws/rest/authentication/token/]. HTTP status 401 [status code: -805306355] [error message: INVALID_CREDENTIALS]
0 -
Your Audience Values in Okta needs to be the same as your Recipient and Destination URL's and the same value present in the Trusted Audiences section of the SAML authentication handler.
The above KB article has been updated with this change in behavior in the later OTDS versions. You also can't take an assertion out of the OTDS logs anymore it needs to be generated from the IDP using its API's.
Jamie Pepper
Sr Technical Analyst
OpenText0 -
Hi,
I'm trying to authenticate user by OAuth2 token that i'm retrieving from Azure. Similarly as described above, when I walk through authentication process in web, i can authenticate and log in to CS in my case.
But when I try the same with OTDS REST call to /authentication/token (testing directly from OTDS API page) and provide my token that I receive from Azure via API i get an error:
Cannot deserialize value of type `byte[]` from String "....token......": not a valid `byte` value at [Source: (org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream); line: 3, column: 5] (through reference chain: com.opentext.otds.restful.AuthenticationParams["tokenBinary"]->byte[][0])
Nothing gets recorded in OTDS log and request fails with 400.
This endpoint (/token) has multiple parameters besides tokenBinary, what is the purpose of them and is any of them required for OAuth2 to work?
OTDS 21.3.0
Thanks,
Ugis
0 -
I managed to move a bit further. Appears that Oauth2 token that I get from Azure must be converted to base64 before feeding in to OTDS.
Now, i'm seeing following in OTDS log:
2021-10-05 11:11:18.080|DEBUG |[https-jsse-nio-8443-exec-1]|OAuth2Handler||Obtained user object: {"aud":........}
2021-10-05 11:11:18.080|DEBUG |[https-jsse-nio-8443-exec-1]|OtdsAuthenticationManager||Authentication attempt for username [token] with handler AzureOAuth2 result {FAILURE, null, null, null}
2021-10-05 11:11:18.080|DEBUG |[https-jsse-nio-8443-exec-1]|OTDSExceptionMapper||Error from REST API for [POST /otdsws/rest/authentication/token]. HTTP status 401 [status code: -805306355] [error message: INVALID_CREDENTIALS]
And otds-access log:
2021-10-05 11:11:18.080|WARN ||0|0|Authentication Service|Failure Access|28,Initial authentication failed|...|"..."||"Unknown User"|"Authentication failure [INVALID_CREDENTIALS]: Unknown User for resource __OTDS_AS__"
At the same time auth in browser using the same handler works just fine.
Any ideas what is still missing? Why does OTDS can't identify user from token?
2 -
@sandeepvk1234 I am seeing a similar issue. Do you remember what was the misconfiguration and how did you fix it?
0 -
Hi @sandeepvk1234 ,
I am having a similar issue, do you remember the misconfiguration you had?0 -
Hi
Are there updates about this topic? because i am having the same problem of @Ugis e i am interested about a possible solution.
Thanks in advance
0 -
I had the same problem of @Ugis and I resolved in this way:
- i take the Id_Token (NOT THE ACCESS TOKEN) from the Azure Token generated by postman
- convert the id_token in base64 (Otherwise OTDS give a message error)
- use the otds REST api https://<Content Server>/otdsws/rest/authentication/token and insert in the body the BinaryTicket:<Id_token base64>
The last call give a OTDS ticket that can be used for OTCS REST API
I hope this can be useful
0
Categories
- All Categories
- 122 Developer Announcements
- 53 Articles
- 151 General Questions
- 147 Thrust Services
- 56 OpenText Hackathon
- 35 Developer Tools
- 20.6K Analytics
- 4.2K AppWorks
- 9K Extended ECM
- 917 Cloud Fax and Notifications
- 84 Digital Asset Management
- 9.4K Documentum
- 31 eDOCS
- 181 Exstream
- 39.8K TeamSite
- 1.7K Web Experience Management
- 8 XM Fax
- Follow Categories
- Docker Automation
- LiveSite Content Services (LSCS) REST API
- Single Page Application (SPA) Modules
- TeamSite Add-ons
If you are interested in gaining full access to the content, you can register for a My Support account here.