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.
It would probably fit around the same area where mapping of
attributes
is performed.
As there you can get things like group information that you can act upon
in your plugin.
Simo.
--
John