Issues setting up SSO with Azure AD

Andrew, I hate to say this, but there’s a bug right now with SAML User Provisioning for Active Directory that will prevent it from working at all — we’re working to resolve this ASAP. 

Thank you for the reply Zach.
I was sure it was because I was using the Azure AD subscription included with Office365.  I saw that if I were to have an Azure AD Premium P1 subscription, I can modify the assertions returned to Skuid to match what its looking for.  The only thing I couldn’t understand was the Federation ID.  What do you map that to? a GUID of the user? the Domain?

A Premium P1 subscription lets you modify the SAML Attributes sent with the assertion?!? How much does that cost? That would be fantastic. I also am just using the Office365-included Azure AD subscription right now — I will look into this.

Currently during User Provisioning, Skuid does some predefined mappings from SAML Attributes to Skuid User object fields. There are a number of inbound attribute names that Skuid looks for corresponding to each Skuid User column required for User creation. Here are the possible mappings. Whichever attribute is encountered first for a given User column will be used.

First Name

• User.FirstName
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
  

• User.LastName
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

• User.Email
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

• User.Username
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
  

• User.FederationId
• User.Username
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
  

We have rolled out a fix for this to Production. It should now be possible to do User Provisioning using Azure Active Directory.

Some key limitations to be aware of right now with User Provisioning:

- The default Profile for new Users is currently always set to the “Standard” Profile. We are planning to make this configurable in our next major release. For the time being though, you will need to edit the Standard Profile to configure which Apps and Data Sources the Standard Profile has access to so that when Users login they will not 

- When freshly-provisioned Users log in for the first time, they are always sent to the route “/ui”. The consequence of this is that if a User is provisioned through User Provisioning, the first time that User logs in, they will be sent to the “/ui” route and will see the “Forbidden” page, UNLESS you modify the Standard Profile to grant it the “Configure Site” Permission, which gives Users with that Profile the ability to configure anything in your Skuid Site. We are planning to make this “default route” configurable in our next major release, by enabling you to define a Default App for a Profile – when a User logs in for the first time, they will be taken to the Default Route for their Profile’s Default App. On subsequent logins, they will be taken to the most-recently-visited Route. 

Hey Zach,
Ya, the P1 subscription lets you add “Custom” Applications from the Marketplace.  From there you can configure settings for the assertions, User Provisioning, etc…  Not sure what the procedure is, but maybe looking into getting Skuid added to the App Marketplace might be a good idea.  :)  The P1 subscription is pretty pricey, around $6 - $8 / user / month.

Here’s a link to the doc on customizing the claims…
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-claims-customi…

So what kind of ETA do you think for a resolution?  No pressure, just wondering what I should tell the “higher ups”  :)

Actually there’s an easy way to circumvent the “/ui route for standard users” problem: the first time you’re telling brand-new Users to login, just send them to the route that you want them to end up on after performing SAML, e.g. if you want them to start on /home, send them to:

https://YOUR-SUBDOMAIN-us-trial.skuidsite.com/home

They’ll be sent to the login screen, where they’ll see a “Login with SAML” link. Once they click this and are logged in, they’ll be sent to the original URL they went to, rather than the default “/ui” route. 

Hey Zach,
Did you notice the entry that is being set for “email” in Skuid is off for users that are provisioned?  Instead of an email address, its this:

BoJZwWCxBeUgoPz-yOTXKjX7eEn8d-Ljjdw29-LsulQ

The way to get around this is to change the “Request Name Id Format” setting from “Unspecified” to “Email Address”.

Hi Zach,
Just wanted to say a big thanks for resolving this so fast.