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.