SP Authentication based on group membership

Dave Perry Dave.Perry at hull-college.ac.uk
Mon Oct 6 04:36:15 EDT 2014


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 at hull-college.ac.uk *

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] 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

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

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

**********************************************************************
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


More information about the users mailing list