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?
--
HJ