On 03/05/2016 20:52, Simo Sorce wrote:
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.



John actually has a fairly good grip on what I was proposing, I think.  I do want the IdP to fail for some SPs and not others.  My understanding of SAML2 and the various related protocols is limited enough that I don't really see the issue with doing that.  Ipsilon is already arguably doing both authentication and authorisation in many cases (if you're using Ipsilon with FreeIPA, you need an HBAC rule to permit your login), and sending attributes if it succeeds.  The SP has no real idea of the user session with the IdP, and an SP that a user isn't allowed to use has no knowledge of, and needs no knowledge of, another SP they are allowed access to.

My experience thus far is that the SP implementations I've worked with don't have the logic to do the authorisation checks themselves (I've not found a way to do it in GitLab yet, for example), so centralising it in the IdP seems like a sensible enough idea.

Reading a bit on XACML seems to indicate it's aimed at doing very fine-grained access control within applications, down to the record / resource level.  I'm not suggesting Ipsilon do that (well, not yet, we could do XACML one day I'm sure), I'm just after more control over the situations in which the IdP says yes.  Another concern I have is that just getting software to have working SAML2 support is hard enough, adding other protocols on top of that is just going to compound the issue.  SAML2's IdP-initiated logout seems to be far from universally supported.

-- 
HJ