On Tue, 2016-05-03 at 15:44 -0400, John Dennis wrote:
On 05/03/2016 01:50 PM, Simo Sorce wrote:
> On Tue, 2016-05-03 at 18:17 +0100, Howard Johnson wrote:
>> I think I vaguely brought this up on IRC a while back, and I've been
>> meaning to send a mail to the list about it.
>>
>> I'd like to see Ipsilon get a plugin-based system for doing
>> authorisation of SP logins. The plugins would allow various data
>> sources to be used to allow or reject a SP login process after
>> authentication has passed, but before the success response is sent back
>> to the SP.
>>
>> (apologies if I'm getting too simplistic here, I just want to be clear
>> what I'm suggesting)
>>
>> The scenario I'm looking at is this:
>>
>> I have a single Ipsilon IdP instance, and a number of SPs configured to
>> use it. I have a number of users of various types whose credentials and
>> attribute data is all in one place (say, a FreeIPA instance behind the
>> IdP). These users are from various different groups, with the different
>> groups needing access to different SPs (e.g. my developers need access
>> to a GitLab instance, but HR doesn't). As it stands with Ipsilon now,
>> any user that can authenticate with the IdP can access any SP. I'm also
>> really lazy, and like my SPs to auto-create local user accounts when a
>> user logs in. If I want per-application control of who can log in to
>> what SP, each SP needs to have its own logic to handle that at the
>> application layer. For in-house and open source applications that's OK
>> (although I'd really prefer not to have to write that code N times, with
>> the associated increased possibility of me making a mistake in that code
>> and letting in unauthorised users), but much more problematic for closed
>> source or
>> open-source-but-not-modifiable-without-invalidating-your-support-contract
>> applications.
>>
>> I'm currently facing this issue looking to deploy Ipsilon myself, where
>> I have applications like GitLab, and various bespoke internal web
>> applications that each need restricting to different groups of users.
>> The latter are less of a problem, but I'd _really_ prefer not to have to
>> learn enough Ruby on Rails to add the functionality to GitLab, when I
>> can add it to a nice Python application instead ;)
>>
>> Any thoughts, anyone? Is this functionality something the project as a
>> whole would like to see added? If so, any thoughts on where in
>> Ipsilon's authentication flows we'd insert it?
>
> Sounds like a good idea.
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.
--
Simo Sorce * Red Hat, Inc * New York