Question about initial user/role setup after enabling SAML SSO

[Yaowen Tu]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130506/222f478c/attachment.html