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?
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.
Simo.
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.
On Tue, 2016-05-03 at 14:25 -0400, Nathaniel McCallum wrote:
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.
They should be surfaced by the krb5 auth plugin and placed in attributes, yes, that would be nice.
Simo.
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.
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.
On 05/03/2016 03:52 PM, Simo Sorce wrote:
John, It doesn't have to be a failure to authenticate at the IdP,
True, but that's not what the OP stated, the OP statement was:
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.
I read that statement as "fail authentication for specific SP's". I do not read this as authentication succeeds and add an extra attribute for the SP to process.
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.
Yes, and that's exactly what I said:
"It shouldn't be hard to add authorization checks in the SP where it belongs. It could be as simple as testing one attribute."
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
Failing authentication and failing authorization are not the same thing.
We already have mechanisms in Ipsilon to add attributes to the Authentication Assertion and that is what should be used for the simple cases (when Authorization Assertions are overkill).
Perhaps the question is better framed as:
Is the attribute injection mechanism in Ipsilon sufficiently rich? Should a plugin interface be developed to allow context specific attributes to be generated?
That is a different question.
On 03/05/2016 20:52, Simo Sorce wrote:
On Tue, 2016-05-03 at 15:44 -0400, John Dennis wrote:
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.
John actually has a fairly good grip on what I was proposing, I think. I do want the IdP to fail for some SPs and not others. My understanding of SAML2 and the various related protocols is limited enough that I don't really see the issue with doing that. Ipsilon is already arguably doing both authentication and authorisation in many cases (if you're using Ipsilon with FreeIPA, you need an HBAC rule to permit your login), and sending attributes if it succeeds. The SP has no real idea of the user session with the IdP, and an SP that a user isn't allowed to use has no knowledge of, and needs no knowledge of, another SP they are allowed access to.
My experience thus far is that the SP implementations I've worked with don't have the logic to do the authorisation checks themselves (I've not found a way to do it in GitLab yet, for example), so centralising it in the IdP seems like a sensible enough idea.
Reading a bit on XACML seems to indicate it's aimed at doing very fine-grained access control within applications, down to the record / resource level. I'm not suggesting Ipsilon do that (well, not yet, we could do XACML one day I'm sure), I'm just after more control over the situations in which the IdP says yes. Another concern I have is that just getting software to have working SAML2 support is hard enough, adding other protocols on top of that is just going to compound the issue. SAML2's IdP-initiated logout seems to be far from universally supported.
On 05/03/2016 05:17 PM, Howard Johnson wrote:
On 03/05/2016 20:52, Simo Sorce wrote:
On Tue, 2016-05-03 at 15:44 -0400, John Dennis wrote:
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.
John actually has a fairly good grip on what I was proposing, I think. I do want the IdP to fail for some SPs and not others. My understanding of SAML2 and the various related protocols is limited enough that I don't really see the issue with doing that. Ipsilon is already arguably doing both authentication and authorisation in many cases (if you're using Ipsilon with FreeIPA, you need an HBAC rule to permit your login), and sending attributes if it succeeds. The SP has no real idea of the user session with the IdP, and an SP that a user isn't allowed to use has no knowledge of, and needs no knowledge of, another SP they are allowed access to.
My experience thus far is that the SP implementations I've worked with don't have the logic to do the authorisation checks themselves (I've not found a way to do it in GitLab yet, for example), so centralising it in the IdP seems like a sensible enough idea.
Reading a bit on XACML seems to indicate it's aimed at doing very fine-grained access control within applications, down to the record / resource level. I'm not suggesting Ipsilon do that (well, not yet, we could do XACML one day I'm sure), I'm just after more control over the situations in which the IdP says yes. Another concern I have is that just getting software to have working SAML2 support is hard enough, adding other protocols on top of that is just going to compound the issue. SAML2's IdP-initiated logout seems to be far from universally supported.
-- HJ
ipsilon mailing list ipsilon@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/ipsilon@lists.fedorahosted.org
I think what Simo and John came to is that it is not according to the rules of SAML to fail authentication based on the access control check. Instead in different situations different attributes can be injected into the assertion and mod_auth_mellon on the SP side can be instructed to use this attribute for the authorization check. This way the spirit of the requirement: make the SP/IdP solution perform access control checks on behalf of the application, is addressed but without violating the protocol and its guidelines. I suspect this implementation would work for your use case. Do you agree?
On 03/05/2016 22:45, Dmitri Pal wrote:
I think what Simo and John came to is that it is not according to the rules of SAML to fail authentication based on the access control check. Instead in different situations different attributes can be injected into the assertion and mod_auth_mellon on the SP side can be instructed to use this attribute for the authorization check. This way the spirit of the requirement: make the SP/IdP solution perform access control checks on behalf of the application, is addressed but without violating the protocol and its guidelines. I suspect this implementation would work for your use case. Do you agree?
I agree that this is one of those letter vs spirit things. Doing this authorisation check wouldn't violate SAML in a way that would make Ipsilon incompatible with other SAML implementations at the protocol level, but it does violate the spirit of the protocol. I'm just more in favour of flexibility in Ipsilon at the expense of protocol correctness than everyone else, it seems :)
My view is that as the IdP has all the information it needs (with the addition of some extra SP config) to make an authorisation decision, so sending the data to the SP to make that decision is wasted resources if the SP is just going to reject the user. I can also imagine some situations where the IdP may have access to more data than the SP does (i.e. the IdP has a set of attributes for a user that will be filtered out of the assertion sent back to the SP). There's also an argument (ok, not a good argument) to be made from an information security point of view that sending data to an application that isn't going to use it is a bad thing.
I think it's also worth bearing in mind that mod_auth_mellon isn't the only SP game in town, and they don't all have the same feature set. mod_auth_mellon does implement pretty much all the features of SAML2 from what I see, but its apparent limitations (primarily the fact that it doesn't appear to have a method to share the user session cache, which causes problems for load balancing users across multiple servers, plus the fact that not everybody uses Apache these days) mean that for most of the use cases I'm looking at, mod_auth_mellon wouldn't be involved. I keep mentioning GitLab because it was one of the main triggers for me wanting this functionality in Ipsilon. GitLab uses the Ruby Omniauth SAML library, which is pretty limited, with all authentication done at the application level, not in nginx. It's hard-coded to only look at a few specific attributes (email, name, firstname, lastname), and it doesn't have any support for IdP-initiated logout. GitLab doesn't have any code for using SAML data to map users into local groups, or reject user authentication based on attribute values. I don't have particularly high hopes that other implementations are much better.
ipsilon@lists.stg.fedorahosted.org
-
Dmitri Pal -
Howard Johnson -
John Dennis -
Nathaniel McCallum -
Simo Sorce