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.

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.

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