On Tue, 2016-05-03 at 15:44 -0400, John Dennis wrote:I'm not so sure it is a good idea. In SAML the IdP performs authentication and the SP performs authorization based on the contents of the assertion, unless you implement a PDP (Policy Decision Point) which can evaluate a SAML AuthorizationDecisionStatement. In either case your SP needs to act as a PEP (Policy Enforcement Point). If I understand your request correctly you want to fail the AuthnRequest for certain user/SP combinations. This is not SAML. In SAML there are 3 types of assertions: * Authentication Assertion: An assertion that carries business data about successful authentication performed on a subject (for example, a service requester). * Authorization Decision Assertion: An assertion that carries business data about an authorization decision. For example, the authorization decision may indicate that the subject is allowed to access a requested resource. * Attribute Assertion: An assertion that carries business data about the attributes of a subject. If I understand your proposal you're trying to pervert an Authentication Assertion into some type of Authorization Decision Assertion but the two are clearly different. The IdP maintains a session for the user. How can a session be valid for one SP and not another SP? This is not SAML. This is not federated identity. What does it mean for a user to pass correct authentication credentials to the IdP but have the authentication fail because it originated from an SP the user was not authorized on? It shouldn't be hard to add authorization checks in the SP where it belongs. It could be as simple as testing one attribute. How are you going to allow the use of other IdP's which do not have this non-standard feature. If you prohibit all other IdP's you're not really doing federation. Maybe your actual request is for Ipsilon to act as a PDP or better yet support for XACML. The expressiveness of authorization decision statements in SAML is intentionally limited. More-advanced use cases are encouraged to use XACML instead.John, It doesn't have to be a failure to authenticate at the IdP, it can simply be a plugin that inserts a single attribute as the result of some rule checking that will tell whether the user should be allowed in. mod_auth_mellon, and most other SP software already have rules to check for attributes and fail authentication if they do not match specific values. IMO it is a valid use case and the implementation can be perfectly SAML compatible, even in the spirit (ie failing authorization at the SP instead of the IdP, even though that is just semantics for the most part). Simo.
-- HJ