OpenID Connect support merged
by Patrick Uiterwijk
Hi all,
Just a quick headsup for those that missed it: as of earlier today,
Ipsilon now has a full implementation of OpenID Connect and OAuth2 in
the master branch.
There are a few things I want to add before rolling a full release,
primarily the admin interface, but please feel free to test this
implementation out and take it for a spin.
It passed the OpenID Foundation certification test suite for all five
profiles (Basic, Implicit, Hybrid, Config and Dynamic), and I will be
looking at getting the Ipsilon
implementation fully certified.
With kind regards,
Patrick Uiterwijk
8 years, 1 month
RFC: Pluggable IdP-side authorisation
by Howard Johnson
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
8 years, 1 month
Ipsilon 1.2.0 released
by Patrick Uiterwijk
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi all,
This release has been way overdue, and the next version should come a
lot sooner,
but I am very happy to finally announce Ipsilon v1.2.0!
Main changes since 1.1.1:
- - Add SAML2 IdP-initiated login
- - Support mod_nss and mod_ssl from the same config file
- - Some logging fixes
- - Ipsilon specific PAM file
- - Support for newer python-pam versions
- - Add tool to create configuration file from database
- - Fix displaying of move markers
- - SAML2 SP name can now be hostname
- - SAML2 logout bugfixes
For detailed logs, please see the release page at
https://fedorahosted.org/ipsilon/wiki/Releases/v1.2.0
With kind regards,
Patrick Uiterwijk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJXJ7laAAoJEIZXmA2atR5QhscP+wYIRewY361WC2T0L3AKAf6C
+P+XOnei4PkCZsWK0Gk4uIJPaw4V/DlhWO5uTaFaGy1bAN3rpUrD6KqtqbAGN7bi
4z/bdh99A3rRKyBZRbAUhdii4BF9XnhaPtuE0c6Dkcd1FLkuo0VSiP2JElSauJ6F
MJawqn+rjvYoiN4yhwj4xgZwYW1MfcdQ+dGAxcZz3v6tnSvUKHbuyhD7zZSpVug9
tcllal2BlVDbytcvWP/6sftKy/BaolcmWvmR2vksvb0y9xRiZGX8/c+yCqx5swMY
EQlap2lEo6r0IfoOLbxFCjHpxaVc1isadk+AmlTk++g08PK6ppNZg1Gu2KecCR8c
L+tTDPy8qjZTZUc5R7lPaLqU+68xRUkmP4cVETuF4OzN7IE4O/K1WLEDhseAynsh
EG/0A8JhI9F7ccNcIXosO9MSpHsCm45LHa4zc7YgS/E/9mGlS6TAQg73yIvwJbed
9ebofDEqQvCy2GbEwIv1zEq5ncyBwL82zsP2BIysMITQMkYl1H4kIYST4Jr4T2O2
XPZ4G1jQS2yeuW85hFuonkDUeGj/J+UfUyNEnwgWOk1X1CZcykKBFJfXinsQZ5NU
u/a0X4KfRQP5GumAfNKtS7j3hHffGiCLcATwr6BMb6Uv1nZfNp8wWC2k/QcFvqMb
fbOi34ssLUvRA4uDtY33
=nHfp
-----END PGP SIGNATURE-----
8 years, 1 month
Ideas for more powerful attribute mapping
by Patrick Uiterwijk
Hi,
I have been thinking about this for a while now, and a question on our
IRC channel earlier today
got me thinking about it again.
Our current implementation for attribute mapping in provider plugins
works for basic cases, but has
a set of limitations.
For example, it is not possible to map when the attribute is more than
2 levels deep, and the only
mapping we support is a literal mapping of one attribute to another.
In the past, we discussed adding a more extensive mapping and
filtering system system, but that was
deemed as being too complicated to set up for admins.
I was thinking that we might be able to make the attribute mapping
quite a bit more powerful by adding
some indicators after which we would parse the values differently.
Two that I would like to propose are " and !, for respectively literal
text and executed python code.
So, for example, to always provide the text "mycompany" via the
attribute companyname, one would
configure the "companyname" attribute to be mapped to: "mycompany".
If they would want an even more powerful system, they could do
something like !return username.lower()
to get it processed by Python.
If none of those characters are detected in the first place, it would
do a standard recursive lookup, like
we do now. To make it possible to map more than two levels, we could
allow strings like _extras/ldap/uid.
With this setup, admins who need it simple can continue to use their
current configuration, but admins that
need more power would be able to get it.
This is just a thought, but does anyone have feedback on it?
Regards,
Patrick Uiterwijk
8 years, 1 month