Question about initial user/role setup after enabling SAML SSO

[David Langenberg]

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