Question about initial user/role setup after enabling SAML SSO

[Yaowen Tu]

Got it. Thank you so much again.

Yaowen


On Mon, May 6, 2013 at 11:39 AM, Mike Flynn <shibbolethlynda at yahoo.com>wrote:

> FWIW, our system uses a separate login for administrators to manage
> account options and produce reports.  All other users go through SSO.
>
>   ------------------------------
>  *From:* Yaowen Tu <yaowen.tu at gmail.com>
> *To:* Shib Users <users at shibboleth.net>
> *Sent:* Monday, May 6, 2013 11:25 AM
> *Subject:* Re: Question about initial user/role setup after enabling SAML
> SSO
>
> David,
>
> Thank you so much. I really appreciate it. Can I have two follow up
> questions?
>
> 1. For solution 1, we know this is the preferred way, but we have some
> concerns. can you tell me a bit more details about as an SP how to support
> this?  Do you return role information in Assertion? What if SP has a
> different set of roles than IdP? Does SP need to define some kind of
> mapping? What if in SP we have more detailed roles like(admin, operator,
> reader, manager), but not all the roles are existing in IdP system?
>
> 2. For your Option3, I don't quite get what you mean. Can you tell me how
> do you achieve this: "You setup the initial SSO with me and I'll send a
> user across with the Administrator role in the assertion."?
>
> Thanks,
> Yaowen
>
> Yaowen
>
>
> On Mon, May 6, 2013 at 7:45 AM, David Langenberg <davel at uchicago.edu>wrote:
>
> On May 5, 2013, at 7:29 PM, Yaowen Tu <yaowen.tu at gmail.com>
>  wrote:
>
> > Hi,
> >
> > This question is not about how to integrate with SAML or how to use Shib
> products. But I am pretty sure people here have had the same problem that I
> am facing, so I am just looking for some advices. If it is not the correct
> place, please let me know.
> >
> > We are a service provider, and we are using Shibboleth SP. Suppose in
> our application, we originally have our own user/role management. Different
> users with different roles are allowed to use different features. So that
> when a user login we need to know which roles this user has, and prepare
> appropriate UI. We have administrator role, users with this role can assign
> roles to other users.
> >
> > We are thinking of enabling SAML SSO for our application, now the
> problem is how do we setup roles for each user.
> >
> > Solution 1, we relies on IdP to provide role information for each login
> user, the role information may come along with Assertion, but this may not
> work for all the IdPs.
>
> This would be our preferred method.  Several SPs that we integrate with
> have us do this, and it's very convenient in that it makes it extremely
> easy for us to tie in your SPs authorization settings with our central
> authorization database (we use Grouper by Internet2).  This way as users
> turn-over the service admin does not have to do anything special in regards
> to managing user roles.  Now, the one request I would make if you do go
> this route is to NOT require that a user have only ONE single role.
>  Rather, be able to handle the case of a user coming in with more than one
> role applied to them.  If two roles are completely orthogonal to each-other
> use a UI element in the application to allow the user to choose which role
> they'd like to use for this session.
>
> > Solution 2, we only retrieve user from the IdP, and manage the roles in
> our own application. For example, when we get an Assertion, we retrieve the
> username(or email address), and match with a record in our DB, if it
> doesn't exist we automatically create one for this new user. Then we rely
> on users with administrator role to assign correct role for this new user.
>
> This is a bigger pain to manage at scale as it means either writing custom
> integration software to manage roles in your app, or hiring a person to do
> it.  Certainly increases overhead and costs associated with using your
> product.
>
> >
> > Now the questions is where is the first administrator coming from? Our
> customer gets our application, and turns on SAML SSO, now there is no users
> in the DB yet, then how can we resolve such bootstrapping issue? Is there
> any kinds of standard way? We have come up with different options but not
> sure which is better and what are the concerns for each options.
> >
> > Option 1, have a default built-in administrator user. There is a regular
> native login page that built-in users can login without going through
> IdP(there is an option to turn it on/off if SAML SSO is enabled)
>
> This is typically how I've seen it done.  It is also good in that if the
> SSO system goes offline for whatever reason, the admin can still get into
> your app.
>
> >
> > Option 2, during SAML SSO setup, ask for the administrator user name, so
> that we automatically create this user in our DB with administrator role.
> Then when this user login through IdP we could match him in our DB.
>
> Not as common, but a couple of our vendors went this route.
>
>
> Option 3: you provision on first login.  You setup the initial SSO with me
> and I'll send a user across with the Administrator role in the assertion.
>  Their account is automatically created and they're dumped into the app in
> admin mode.
>
> Dave
>
> --
> David Langenberg
> Identity & Access Management
> The University of Chicago
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130506/4bcbaa10/attachment-0001.html