SP Authentication based on group membership

[Cantor, Scott]

On 10/3/14, 8:33 PM, "Christopher Bland" <chris at fdu.edu> wrote:
>
>I am in the process of changing the backend of an IDP to authenticate
>against AD.  With the change I want to take advantage of group membership
>to restrict services.  So far I am thinking I can create a special
>handler for each service which is available to a subset of my users.  The
>LDAP query would be something like username, password and is a member of
>group X.  Now comes the tricky part.

We wouldn't encourage that, the intention is that you pass that group to
the SP and let it enforce the policy, or if you must, use an add-on to
block the response after authentication based on the attributes.

>Once a user has authenticated at an entitled service and then goes to my
>restricted service is there any way to restrict them other than forcing
>an mandatory authentication for the restricted service?

Not unless you define authentication methods and AuthnContext classes to
restrict the login handlers used in different cases, and that only works
if the SP does the right things, and you're essentially talking about SPs
that can't even handle errors, so that's a non-starter to me.

>I also want to take advantage of forcing password changes and account
>locking.

There's nothing provided for that. Account locking doesn't belong in the
IdP IMHO, it belongs in the authentication source. There is substantially
more support for context-aware error handling in V3 when there are signals
back about the state of an account and customizing the login process.

>  I was curious what kind of things the Shibboleth community has tried.
>I have read some good idea from previous posts but wonder if you can
>dynamically change the target in an auth request?

I don't know what you mean by that.

-- Scott