By: Lindsay Weir user 07 Aug 2019 at 10:59 a.m. CDT

13 Responses
Lindsay Weir gravatar
I am trying to configure multiple Tableau sites to use SAML through Gluu. Each site in the application is a separate SAML configuration (different user base) My problem is trying to detect the different SAML environment coming from the same Gluu Client and specifically dealing with a '?' character in the entityId. From the gluu client perspective the Tableau server is considered a single client ID. The SAML identityId can be changed for the Tableau server but it adds in the site specific id automatically and this cannot be changed from the application side. For example: Site A: entityId=https://analytics-dev.work.local/samlservice/public/sp/metadata?alias=eb4c67ea-b622-4b05-864e-9d9ac10d3f5b Site B: entityId=https://analytics-dev.work.local/samlservice/public/sp/metadata?alias=d3da8f57-95a7-4ece-a930-3c9dfc011a07 Note that there is a '?' in the entityId value being passed in the SAML request and each site is differentiated by the alias extension. So, in the SAML exchange we can see everything is in the request URL to the Gluu server initially (the entityId is still intact) https://idp-dev.ids.xxx.ninja/oxauth/restv1/authorize?response_type=code &client_id=%40%2183C0.E893.0E3D.CFDE%210001%218A12.CDBD%210008%218C6D.2374 &scope=openid+email+user_name &redirect_uri=https%3A%2F%2Fidp-dev.ids.xxx.ninja%2Fidp%2FAuthn%2FoxAuth &state=eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJjb252ZXJzYXRpb24iOiJlMnMxIiwic3RhdGUiOiJ1YVJKUjQ3bXJkIn0. &nonce=ijmwAUuf6u &entityId=https://analytics-dev.work.local/samlservice/public/sp/metadata?alias=d3da8f57-95a7-4ece-a930-3c9dfc011a07 The next SAML exchange to the Gluu Server is: https://idp-dev.ids.xxx.ninja/oxauth/authorize.htm?scope=openid+email+user_name &response_type=code &redirect_uri=https%3A%2F%2Fidp-dev.ids.xxx.ninja%2Fidp%2FAuthn%2FoxAuth &state=eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJjb252ZXJzYXRpb24iOiJlMnMxIiwic3RhdGUiOiJ1YVJKUjQ3bXJkIn0. &nonce=ijmwAUuf6u&client_id=%40%2183C0.E893.0E3D.CFDE%210001%218A12.CDBD%210008%218C6D.2374 You can see the 'entityId' is dropped. It is at this point that we can utilize the Glue Custom scripts (in particular the Person Authentication scripts) I can use the 'JSON Configuration'->'oxAuth Configuration'->authorizationRequestCustomAllowedParameters and add a new item and add 'entityId' to allow this parameter to be passed through. Now we get this coming through, but..... https://idp-dev.ids.xxx.ninja/oxauth/authorize.htm?scope=openid+email+user_name &response_type=code &entityId=https%3A%2F%2Fanalytics-dev.work.local%2Fsamlservice%2Fpublic%2Fsp%2Fmetadata%3Falias &redirect_uri=https%3A%2F%2Fidp-dev.ids.xxx.ninja%2Fidp%2FAuthn%2FoxAuth &state=eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJjb252ZXJzYXRpb24iOiJlMnMxIiwic3RhdGUiOiJ1YVJKUjQ3bXJkIn0. &nonce=ijmwAUuf6u&client_id=%40%2183C0.E893.0E3D.CFDE%210001%218A12.CDBD%210008%218C6D.2374 If you noticed, it strips everything after the word 'alias' entityId=https://analytics-dev.work.local/samlservice/public/sp/metadata?alias=d3da8f57-95a7-4ece-a930-3c9dfc011a07 becomes: entityId=https://analytics-dev.work.local/samlservice/public/sp/metadata?alias The issue of course is with the '?' in the entityId key/value pair is also the separator from the URI 'https://idp-dev.ids.xxx.ninja/oxauth/authorize.htm' and the request parameters. Having said that, it appears it was handled correctly on the previous requests but the authorizationRequestCustomAllowedParameters doesn't pass it through. I have tried various options to try to back quote the characters in this section but to no luck. The below is take from the SessionState from within the Custom script which also sees the stripped entityId SessionState {dn='oxAuthSessionId=7faf6180-e7fc-422e-878a-57bb105d59d5,ou=session,o=@!83C0.E893.0E3D.CFDE!0001!8A12.CDBD,o=gluu', id='7faf6180-e7fc-422e-878a-57bb105d59d5', lastUsedAt=Wed Aug 07 01:13:45 UTC 2019, userDn='', authenticationTime=Wed Aug 07 01:13:45 UTC 2019, state=unauthenticated, sessionState='650f23efcf62183019ff8113a55159e0dd8d6d29832493a976e48c2afb0c5cf6.05f858e8-d5f8-45e8-bf72-814f6ff7c337', permissionGranted=null, isJwt=false, jwt=null, permissionGrantedMap=org.xdi.oxauth.model.common.SessionIdAccessMap@6a2ae1f3, involvedClients=null, sessionAttributes={auth_step=1, acr=xxx_authentication, remote_ip=10.92.81.39, opbs=07ce6bb6-5c2a-4c3a-99bd-9ac29157f65c, scope=openid email user_name, response_type=code, entityId=https://analytics-dev.work.local/samlservice/public/sp/metadata?alias, redirect_uri=https://idp-dev.ids.xxx.ninja/idp/Authn/oxAuth, state=eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJjb252ZXJzYXRpb24iOiJlNHMxIiwic3RhdGUiOiJHYTNZYkNxMFZqIn0., nonce=nlV9tYWkCI, client_id=@!83C0.E893.0E3D.CFDE!0001!8A12.CDBD!0008!8C6D.2374}, persisted=true} I tried playing with the other Custom scripts to see if anything is able to intercept the 'https://idp-dev.ids.xxx.ninja/oxauth/restv1/authorize' stage before. If there is somewhere I can intercept the request, I can always pull out the alias portion of the identityId and add a new header as a possibility. Looking for any assistance or suggestions as this is a blocker for me at the moment as I am unable to get the entityId into the Person Authentication Custom Script where I need it to distinguish the different source systems. If there is some other method I can use to distinguish the source SAML entity then that might work but I don't appear to see anything different in the headers or payloads that I can successfully use.

By Aliaksandr Samuseu staff 07 Aug 2019 at 11:06 a.m. CDT

Aliaksandr Samuseu gravatar
Hi, Lindsay. That's interesting. Thanks for reporting it, I'll ask dev team to look into this. We'll get back to you soon.

By Michael Schwartz staff 07 Aug 2019 at 11:17 a.m. CDT

Michael Schwartz gravatar
re-assigning to @malotian

By Aliaksandr Samuseu staff 07 Aug 2019 at 12:23 p.m. CDT

Aliaksandr Samuseu gravatar
A note to @HARJINDER.DHANJAL : Yuriy Z thinks it may be a bug in oxAuth. He suggests to create a bug report at Github (oxAuth repo) after successfully reproducing it locally.

By Lindsay Weir user 07 Aug 2019 at 11:27 p.m. CDT

Lindsay Weir gravatar
Were you able to reproduce this error locally today?

By HARJINDER DHANJAL staff 11 Aug 2019 at 7:33 p.m. CDT

HARJINDER DHANJAL gravatar
looking into this, just a question, is it possible to URL encode entityID in query string and use in along with person script problem/culprit is two '?' one is authorize? and another is ?alias that's why webserver will drop secod '?' (that some how makes complete url invalid) https://idp-dev.ids.xxx.ninja/oxauth/restv1/authorize?response_type=code &client_id=%40%2183C0.E893.0E3D.CFDE%210001%218A12.CDBD%210008%218C6D.2374 &scope=openid+email+user_name &redirect_uri=https%3A%2F%2Fidp-dev.ids.xxx.ninja%2Fidp%2FAuthn%2FoxAuth &state=eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJjb252ZXJzYXRpb24iOiJlMnMxIiwic3RhdGUiOiJ1YVJKUjQ3bXJkIn0. &nonce=ijmwAUuf6u &entityId=https://analytics-dev.work.local/samlservice/public/sp/metadata?alias=d3da8f57-95a7-4ece-a930-3c9dfc011a07 Solution/Option can be/will be https://idp-dev.ids.xxx.ninja/oxauth/restv1/authorize?response_type=code &client_id=%40%2183C0.E893.0E3D.CFDE%210001%218A12.CDBD%210008%218C6D.2374 &scope=openid+email+user_name &redirect_uri=https%3A%2F%2Fidp-dev.ids.xxx.ninja%2Fidp%2FAuthn%2FoxAuth &state=eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJjb252ZXJzYXRpb24iOiJlMnMxIiwic3RhdGUiOiJ1YVJKUjQ3bXJkIn0. &nonce=ijmwAUuf6u &entityId=https%3A%2F%2Fanalytics-dev.work.local%2Fsamlservice%2Fpublic%2Fsp%2Fmetadata%3Falias%3Dd3da8f57-95a7-4ece-a930-3c9dfc011a07

By Lindsay Weir user 11 Aug 2019 at 8:49 p.m. CDT

Lindsay Weir gravatar
Unfortunately we have no control of this. The source application is Tableau.

By Michael Schwartz staff 11 Aug 2019 at 9:22 p.m. CDT

Michael Schwartz gravatar
As this is an SP config issue... closing.

By Lindsay Weir user 11 Aug 2019 at 9:27 p.m. CDT

Lindsay Weir gravatar
EntityID can be anything. gluu supports parsing the key prior to the script phase correctly. Not sure why this is being closed?

By HARJINDER DHANJAL staff 11 Aug 2019 at 10:06 p.m. CDT

HARJINDER DHANJAL gravatar
Yes, please change entity id to be URL encoded in config screens - https%3A%2F%2Fanalytics-dev.work.local%2Fsamlservice%2Fpublic%2Fsp%2Fmetadata%3Falias%3Dd3da8f57-95a7-4ece-a930-3c9dfc011a07

By HARJINDER DHANJAL staff 11 Aug 2019 at 10:08 p.m. CDT

HARJINDER DHANJAL gravatar
Change SP Configs as suggested

By Lindsay Weir user 11 Aug 2019 at 10:23 p.m. CDT

Lindsay Weir gravatar
The vendor’s software does not allow the changing of the ‘?alias=…….’ Portion of the entityId string. https://help.tableau.com/current/server-linux/en-us/saml_site_specific.htm At the bottom of the page under ‘Step 1’ it details this. If we configure each site pointing to a separate Gluu Server then it works fine, just when we direct both configurations from the same server (different sites) to the same Gluu Server, we run into this issue. Directing it to different Gluu servers just allows us to hard code in a login.xhtml and server side script for each but this is not an efficient utilization of resources on the Gluu Server side as we want to have up to half a dozen configurations with different SAML configurations moving forward from just this one environment.

By Lindsay Weir user 11 Aug 2019 at 10:24 p.m. CDT

Lindsay Weir gravatar
If there is some way to intercept the headers (before we get to the login step) then I could extract/rewrite the alias portion out to a new header?

By HARJINDER DHANJAL staff 12 Aug 2019 at 8:36 a.m. CDT

HARJINDER DHANJAL gravatar
We can work on supporting this, but it would require some custom development. This is something we can evaluate further if your organization has a support contract. Feel free to schedule a call with us to discuss: https://gluu.org/booking