This new feature may seem small because its UI surface is constrained within lesser-used screens, but it packs a whole lot of punch under the hood. Let's dive into the details of Kentik Portal authentication – the good, bad, and challenging aspects – because there's a lot of new things to unpack today.

Single Sign-On is the modern way of managing access to a broad set of company-wide applications in a structured and more secure way, centralizing access control for all of these applications in the Identity Provider (IdP)  companies have chosen.

When login happens in Kentik using SSO, the Identity Provider presents claims to the Service Provider (in our case Kentik Portal) for each user (user attributes) in a standardized format named SAML2. Each company has a different pre-existing way to define user groups and rely on their IdP to do so.

With this SSO to RBAC attribute mapping feature, Kentik makes it easier and more flexible to leverage your current IdP configuration of user groups to enforce Kentik Portal permissions.

Let's dive in.

---

UserLevel vs RBAC

As Kentik Portal moves to a full RBAC permissions model, many areas are still governed by our legacy UserLevel permission model: we have three types of users, each one with a set of implicit permissions – Member, Admin, and SuperAdmin. For all areas of Kentik Portal that aren't governed by RBAC, UserLevel applies:

• Members generally have View only rights
• Admins have Update/Create/Delete rights 
• SuperAdmins are a special case: they are Admins who have the additional power to login using password authentication, even when SSO is required – there needs to be at least one per company, but the lesser the better to keep risk surface as low as possible.

As we progressively extend the surface of portal areas that are governed by RBAC, these areas will not be covered by UserLevels anymore – but in the meantime, we maintain both.

What our users have been asking for

Many customers with a large Kentik user-base have asked for RBAC permissions to be controlled centrally from their Identity Provider, which implied the following requirements:

• Kentik Admins want to control RBAC permissions directly through their SSO Identity Provider, as managing users at scale requires a centralized approach and dedicated tool outside of Kentik's User Administration page. Additionally, not all users want or need to enforce RBAC permissions via SSO – some are OK with using Kentik Portal's User Management capabilities, meaning both methods need to co-exist.
• Kentik Admins want to leverage their existing IdP configuration without modifications. Typically, the SSO team prefers to not create new groups for Kentik, but instead use existing groups. 
• Some SSO IdPs allow users to belong to multiple groups. This usually results in nested User Groups being presented to authentication by the IdP, and Kentik SSO needs to accommodate this reality.
  This is typically the case for more complex SSO Setups bridging LDAP or ActiveDirectory user groups into SSO->SAML2.
• For whatever user attribute key handed out in the SAML2 payload, Kentik Admins don't want to have to create specific values to match what Kentik's Service Provider (SP) end of SSO expects – they want to use existing ones and map them.
• Kentik Admins want to be able to forbid access to Kentik Portal for users that aren't in specific groups (instead of defaulting to Member as our current system does).

Introducing SSO Attribute Mapping

To satisfy the requirements captured in the previous section, we've updated the SSO configuration screens quite drastically to present these new functions.
If you don't see the Company Settings menu entry below, you are not a SuperAdmin and therefore cannot access the SSO settings.

And here's the new "Authentication & SSO" screen layout, notice how it's been broken down in multiple tabs for clarity - the one we'll be looking at is "SSO Attribute Mapping".

As you can see, there are two sections – one for UserLevel SSO enforcement, and the other for RBAC SSO enforcement, since both will coexist for some time.

• The configuration for UserLevel enforcement configuration aspects have changed to this new model
• We've added an RBAC role-set mapping section. Rightfully you're asking, "But what's a Role set ?" – hang on, we'll get to that later ;)

In both of them, the Kentik Administrator can configure the key, which will be presented by their IdP to the Kentik Service Provider end of SSO: the authentication engine will look for the key and its value(s) in the SAML2 assertion presented by your IdP. Upon successful match of the key value, the subsequent UserLevel or Role-Sets will be assigned to the user based on this rule:

• By default, if no key is configured, Kentik Portal will use portal-local user settings for UserLevel or Role-Sets: this is the most common case where you don't want your SSO IdP to dictate user permissions
• If a key is configured, then Kentik Portal will evaluate the value in this key against the mapping table below it:
  • If the configured key isn't found or if the value for this key isn't present in the mappings, then the authentication process will turn to the default setting, as displayed below for UserLevel
    
    
• If a key is configured, and a match is found in the mapping table, then users will be assigned a UserLevel and Role-Set corresponding to the match
• If a key is configured, and multiple matches are found in the mapping table, then users will be assigned:
  • The highest UserLevel matched 
  • A set of permissions that corresponds to the union of all permissions listed in the Role-Sets that are mapped against these values

Let's look at the example below

1. Kentik Portal is expecting the key named kentik_userlevel from the IdP
2. if this key shows up with admin or guest values, the user's UserLevel attribute will be re-written on the fly to Administrator or Member
3. If no key is found, or if the user comes with a value that's different from the mapped ones (admin and guest), the default configuration will apply and the user will be denied access based on the configuration above.

Got it, now what are RBAC Role-Sets ?

Think of Role-Sets as operational sugar to manage user RBAC permissions more easily. In a nutshell, Role-Sets are collections of RBAC Roles. This new concept is introduced in the updated RBAC configuration screen.

The idea behind Role-Sets is that Admins usually want to be able to compose freely with RBAC Roles and Permissions – we realized it would make the Attribute Mapping very noisy if we were to ask our users to map multiple roles to a single Role key value, so we decided to offer an additional level of granularity by allowing users to group multiple RBAC roles in a Role-Set.

The new "Role-Sets" tab in this screen lets you configure these 

And the User Properties (in Company Settings > User Management) now let you assign both Roles and Role-Sets to users.

That's all folks!

As you can see, this feature packs quite a bit of punch and hopefully helps you more efficiently and cohesively manage Kentik Portal security according to moderns SSO standards !

Please let us know what you think – in parallel, we'll keep porting more and more portal areas over to RBAC out of the existing UserLevel model (another big announcement coming your way on that front, stay tuned).

Now, in the "Wait, there's more..." section, here are interesting stats around what SSO IdPs our customers are currently using – and this is the top5 ones we are testing these capabilities against.