Siteminder Introspection Token Endpoint throwing error with different client credenials
search cancel

Siteminder Introspection Token Endpoint throwing error with different client credenials

book

Article ID: 271245

calendar_today

Updated On:

Products

SITEMINDER CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On Federation (SiteMinder)

Issue/Introduction

 

With multiple OIDC client configuration, will SiteMinder allow an introspect call to client2 using to validate an access token generated by client1?

Result from testing showing SiteMinder does not support this since the introspect call is throwing 401.

Is there a workaround or setting in SiteMinder to allow this ? 

 

scenario

Credential used to get Access token

Credential used to call  Introspection endpoint

Result from Introspection End point

Validate accessToken of client 1

Client 1 credential

Client 1 credential

Able to validate

Validate accessToken of client 1

Client 1 credential

Client 2 credential

Error - > 401 Unauthorised

Validate accessToken of client 2

Client 2 credential

Client 2 credential

Able to validate

Validate accessToken of client 2

Client 2 credential

Client 1 credential

Error - > 401 Unauthorised

 

Environment

 

Release :12.8.x

 

Resolution

 

  • The introspect call behavior seen, is expected and by design, since this call requires to pass the correct client credentials (clientID/Secret) associated with the generated Token (even though the call can be done to introspect service without passing the actual client name. But the client credentials are required) .

There is no way around this as of today within SiteMinder .

With that being said, if the purpose of the introspect call is to determine if the token is valid or not, use the userinfo service instead which does NOT required client credentials nor client_ID to be passed.

Below are various scenario on using the userinfo service 

sysuser@_host ~ % curl -Ss -X POST \
https://_host.example.com/affwebservices/CASSO/oidc/userinfo \
> -H 'Authorization: Bearer eyJra [...omitted for brevity...]
4Ig'

 

for a valid token you get :

 

{"sub":"<user ID>","phone_number":"(800) 555‑0100","email":"<username>@example.com"}

 

When it sends the invalid token or corrupted token, it returns as:

 

{"error":"invalid_token","error_description":"Invalid access_token."}

 

When the token is expired or revoked, it returns as:

 

{"error":"invalid_token","error_description":"Invalid access_token."}

 

Open an enhancement request as well for the introspect call and request to include an option in future releases to not require client credentials on the introspect call which will be studied by our PM team and see if this is something that can be considered for future (1).

 

Additional Information