SP Authentication based on group membership

[Christopher Bland]

Hello All,

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.

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? In the past I have not released attributes, which causes an error but this solution only works if the SP/Vendor allows custom error pages so I can let the use know it's restricted versus having an error they don't understand.

I also want to take advantage of forcing password changes and account locking. 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?

-Chris

[Cantor, Scott]

Post by Christopher Bland
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.

Post by Christopher Bland
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.

Post by Christopher Bland
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.

Post by Christopher Bland
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

[Dave Perry]

We weren't able to do anything with the 'force password reset at next login' flag, but only realised it was such a problem when we switched moodle to use AD too (it was going to be shibboleth, but we want true SSO from the desktop and that will be quicker to achieve using AD given IT's workload and our lack of admin-level access to AD and the firewall).

IT came up with something, using some MS-published code, which lets students finish their password reset/set initial password via a web page. But they won't just rush it out as it's sitting in a prototype portal which will have other things in it (like a link to our security questions and answers for password resets system, SpecOps if anyone has heard of it, and links to web services which should then SSO).

So we will likely link to that from our Shibboleth login page, when it's ready.


Dave

_________________________________________________
Dave Perry
eLearning Technologist, Hull College Group

Room L34 - Queens Gardens Library
Wilberforce Drive, Queen's Gardens, Hull, HU1 3DG
Extension 2230 / Direct Dial 01482 381930

* Need a fast reply? Try elearning-NOSDTyrR4+***@public.gmane.org *

-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Cantor, Scott
Sent: 04 October 2014 02:35
To: Shib Users
Cc: Danovan Golding
Subject: Re: SP Authentication based on group membership

Post by Christopher Bland
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.

Post by Christopher Bland
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.

Post by Christopher Bland
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.

Post by Christopher Bland
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

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

**********************************************************************
This message is sent in confidence for the addressee
only. It may contain confidential or sensitive
information. The contents are not to be disclosed
to anyone other than the addressee. Unauthorised
recipients are requested to preserve this
confidentiality and to advise us of any errors in
transmission. Any views expressed in this message
are solely the views of the individual and do not
represent the views of the College. Nothing in this
message should be construed as creating a contract.

Hull College owns the email infrastructure, including the contents.

Hull College is committed to sustainability, please reflect before printing this email.
**********************************************************************

TEXT