Hi, Zach. You'll need to clarify a bit what do you mean by "discrimination" here. It seems you are looking for some kind of authorization capabilities. Like, depending on user, it should, or should not respond with success, or may be it should send different set of attributes. Is it what you have in mind? When it comes to SAML, Gluu doesn't offer any easy-to-use authorization options. You need to do all access rights' checks at your SP, based on the response from Gluu. It's surely possible to configure Shibboleth IdP (which is used by Gluu for SAML-related things internally) to do some kind of authorization, but it will require to edit its config files on disk (no web UI support), and such things are not covered by Community support. You can try Shibboleth docs/forums for details. Those groups you may see are used mainly with [UMA](https://gluu.org/docs/ce/3.0.2/admin-guide/uma/) flows. So, in short, if you need Gluu to handle authorization, it's recommended to use UMA (you can use oxd server, our other product, to add UMA capabilities to app you want to protect), or try to reconfigure Shib IdP, if you have to use SAML.

Ok, yes it seems the best practice is to use the SP as the authorization authority (correct me if I'm wrong on that). So what would be the recommended way to modify local Gluu users to pass along an identifying attribute to the SP so that it can make a decision on user access?

>yes it seems the best practice is to use the SP as the authorization authority (correct me if I'm wrong on that) It's usually like this, correct. Unless you have some special requirements. >So what would be the recommended way to modify local Gluu users to pass along an identifying attribute to the SP so that it can make a decision on user access? Not sure I can fully see your intentions currently. May be you could provide detailed step-by-step of algorithm you want to implement? At the moment, when it comes to SAML, administrator web UI will allow you to create Trust Relationship with your intended SP, and specify a list of attributes you wish to release to it. Then any user sent to Gluu from this SP, if authenticated successfully, will be sent back to SP with SAML response containing all these attributes. Anything else will require to edit Shib's configuration files on disk. There are more options to control what is returned to requester if OpenID Connect is used, but for SAML that's it.

You should schedule a meeting at http://gluu.org/booking and we can discuss your options. Alex is correct that OAuth is better for centralized policy management. If you stuck with SAML, you have to make the app smarter. Or perhaps use a proxy.