By: Challa Rao Ande user 01 Mar 2017 at 3:39 a.m. CST

3 Responses
Challa Rao Ande gravatar
Let's say I have multiple SPs, given that I maintain some list somewhere LDAP/database kind of an access registry for users stating which apps(SP's) they have access to, is it possible to deny sending the assertion for an SP for which user doesn't have access to even though he is authenticated in IDP? 1. User already has session in IDP 2. User accesses SP2 which they don't have access to 3. Gluu checks for the SP and based on magic(script?), it will fetch the access registry and knows that they don't have access to it. 4. Gluu will deny sending the assertion to SP. Is that scenario possible in Gluu?

By Aliaksandr Samuseu staff 01 Mar 2017 at 6:07 a.m. CST

Aliaksandr Samuseu gravatar
Hi, Challa. One thing to clarify: if user is already authenticated and have session at Gluu, that usually means 2 things (in described scenario): 1. He has session at oxAuth 2. He has session at Shibboleth module (which is responsible for SAML part) Gluu consists of independent apps/modules, each of them is a separate Java app. oxAuth glues them all together, it's expected that all of them will first redirect user to oxAuth for authentication. If user's browser was redirected by Shib to oxAuth and was authenticated, if then it was redirected there by CAS module, it won't be asked for authentication and will be immediately sent back to CAS and a session will be created there. All modules "spawn" their session from oxAuth's session, let's say. And custom auth script functionality is feature of oxAuth only. So after user's browser got his session at Shib ("spawned" it from oxAuth session), he will start to use it in SSO manner without contacting oxAuth any more, until his session at Shib will expire (session timeouts will happen independently at all those modules, and can be tweaked). Thus your phrasing was a bit off, it's not Gluu who controls what will be released to what SP in SAML flows, but Shib. So to answer it you need to study Shibboleth IdP's capabilities and resort to modifying its configuration files in container by hand. I only can say that Gluu's web UI doesn't provide you tools to set the flow the manner you want. After initial session is created, user's attribute will be sent to any SP he'll try to access for which Trust Relationship is created in Gluu's web UI. I also know that Shib's SSO feature can be disabled and tweaked, and that it has quite a complex policy mechanics controlling attribute release, so your requirements may well be met by it. But such low-level customizations is out of scope of free community support, unfortunately, and you'll be on your own here. At best, if you'll figure out the exact Shib's settings you need, we could guide you how to edit configuration template files to add them to your instance.

By Michael Schwartz Account Admin 10 Mar 2017 at 4:01 p.m. CST

Michael Schwartz gravatar
The answer is "no". If the SP is trusted, the IDP will send the assertion. Then it's up to the SP what to do with that information. You are trying to fit a square peg in a round hole. If you were to architect around OAuth2, I think what you're trying to do is totally possible.

By Challa Rao Ande user 14 Mar 2017 at 1:11 a.m. CDT

Challa Rao Ande gravatar
Hi Aliaksandr, Thanks for enlightening me more about Gluu. I asked this question to confirm whether those things are configurable by Gluu or I have to do manually as I should with Shibboleth. Michael, That's what my line of thinking too. But just wanted to confirm whether there is a way. Thank you