SAML for MSP/multiple organizations

[mvalpreda]

Trying to figure out the best practice for setting up SAML for an MSP. Want to get away from setting up users in each client dashboard since off-boarding is a pain in the kazoo.

We're using AzureAD for SAML and it's working fine. I set up a new test account and followed everything in the docs. I used the default meraki_read and meraki_write in the roles. Test account was able to get to the two different dashboards I set up.

Now I want to have some granular control with who has access to what customers. What is the best practice for that? I would like to use AD groups, so when I add someone to a group....boom! They get access to that client dashboard. Is that something with the roles? Maybe set up roles like 'client_read' and 'client_write' and add those to the client dashboard? Or is there a better way?

Also noticed if I go to dashboard.meraki.com, the user I set up cannot log in. Is that expected?

[PhilipDAth]

>Also noticed if I go to dashboard.meraki.com, the user I set up cannot log in. Is that expected?

Correct.  Only Idp initiated SAML is supported.

Except maybe I'm lying.  You could use Cisco SecureX (free!) as your SAML provider, and it can back end into Azure AD.  You can log into directly to the Meraki dashboard using that.

https://documentation.meraki.com/General_Administration/Managing_Dashboard_Access/Cisco_SecureX_Sign... 

As a double whammy, you can use Cisco SecureX for a lot of other Cisco products as well.  The limitation - you can only use it for Cisco products.

If you have used almost any other Idp (like Cisco Duo Access Gateway) you come to realise the Idp in Azure is retarded.  It's hard work, and not very configurable.  One of the issues is you can't control the user's launcher.  So they have to add each client to their Azure launcher, and they can see every client.

If you can accept that, then the users will only be able to launch the Meraki dashboards if they belong to the groups that have been assigned an appropriate role.

My thoughts, don't use AzureAD as an MSP.  As an end-user customer for a small number of dashboards, sure.  I've not considered or tried Cisco SecureX for MSP use, but you could consider that.  Otherwise, take a look at a "proper" Idp like Cisco Duo DAG.

One of the main differences with using DAG is you can use it with anything that is SAML compliant (Office 365, Azure, Atlassian, Meraki, AWS, etc) - while Cisco SecureX won't.

Once you have used something like DAG you'll come to love how it is the source of access to everything cloud in your company.  It's hard to explain.  Then you look back at AzureAD SAML and you can't understand why you spent so much time trying to make it work in a way you expect it just should.

[JRobinsonENC]

edited: posted in incorrect reply.

[JRobinsonENC]

So I'm attempting to set this up and I've noticed the limitations of using a Duo DAG in an MSP environment.

The Duo application setup requires the Meraki Consumer URL to be configured for the application. This causes users to login to just one overarching organization in a MSP portal and thus not have access to all other organizations.

How did you get around this with Duo? Any input would be greatly appreciated !

[RomanMD]

I never tried Duo, but I would assume that the same workaround as described by me above, would do the trick for Duo too.

[PhilipDAth]

>The Duo application setup requires the Meraki Consumer URL to be configured for the application. 

This is not a Duo "thing" but a Meraki "thing".  It is the same for all Idps.

It is not correct that it only gives access to one org.  It gives access to all orgs via the MSP portal for which SAML authentication has been configured.

Check out this section on configuring the Idp for MSPs.

https://documentation.meraki.com/General_Administration/Managing_Dashboard_Access/Configuring_SAML_S... 

[RomanMD]

What you are trying to accomplish is achievable as I am doing the same thing. 

I have setup more than 10 Meraki organizations (another 20 to come) and needed to integrate them with SAML Authentication (ADFS). 

The IdP Entity ID should be unique in ADFS, therefore the problem comes when the meraki organizations are located on different shards (different dashboard links). You cannot setup different IdP in ADFS for each organizations. 

So, as a king of workarounds, this is the design I made:

1. I have created a Dummy organization set for SAML authentication with a single Dummy network. 

2. Gave ReadOnly access to all my Meraki roles to the dummy network. All Meraki Roles are linked to the AD groups with the same name.

3. Configured ADFS IdP Assertion Consumer Service (ACS) URL with the URL from dummy organization.

4. Configured rest of the organizations with the same fingerprint for SAML authentication.

6. Added each needed role in the respective aorganization with needed rights for that organization.

Now, when my user logins via ADFS page, the ADFS will redirect the user to the URL of the Dummy org - but since the role has rights in different organizations, meraki will allow user to select the organization from MSP portal. 

This approach works perfect for me since 1 year, but there are few downsides which has to be accepted:

1. The user will see a Dummy organization. That does not impact the functionality, it is just an inconvenience.

2. You should plan your roles very carefully in advance, since one user cannot have more than 1 (one) role assigned. If the user will be part of two AD groups - then only the first group in the list will be sent to meraki. 

So, if you want one user to be able to have read only access to one network in one org, and read write access to another network in another org - you cannot define separate roles for both organizations and add the user to both roles. Instead you have to created a common role for both organizations where you will give different permissions in dashboard. 

3. The SAML login information will be only visible in the Dummy organization, instead of being visible in organization for which he meant to login. The "change log" will be visible in each organization separately. 

4. Camera roles were deployed after my implementation, and strange enough, they don't allow "space" in the name. In the ADFS we have some automation for the role to send - so we have already a filter which includes a space, and I cannot change it - otherwise I have to change the name for 50 AD groups. This might not be the case for you, when you will add each role in Azure manually. We just wanted to avoid touching ADFS every time we want to add new role - since these are two different teams.

But still, if you like to follow some naming concepts, be sure to design the AD groups (role names) without spaces, otherwise you will not be able to use camera roles.

Have fun...

Roman