On Tue, 2016-05-03 at 13:50 -0400, 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.
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.
This would be a good place to try out krb5 authentication indicators.