FIM/MIM in the SaaS world - syncing attributes to SaaS apps RRS feed

  • General discussion

  • We've got a lot of data (employee licenses / charge out rates / first aid certifications / etc) that we would like to synchronize between multiple systems.  I was looking at the REST capabilities of MIM, but MIM seems to be emphasized as a on-premise solution, and Azure AD as the cloud solution.

    My concern is that a lot of the data I'd like to replicate isn't appropriate to put into Azure AD, and Azure AD doesn't really need to know about it.  With FIM, I can synchronize attributes only to the data sources that need them (so our HR System <-> Payroll system for example, without going to the AD data source).

    Does Azure AD have a metaverse-style repository for this purpose? I'm not sure if I've articulated this very well...

    Monday, October 22, 2018 11:59 PM

All replies

  • Based on what you are trying to do you could potentially use the MIM Sync engine for this.  The caveat is if your target SAAS system has an API that you could use to create a custom PowerShell or ECMA agent.

    Azure AD might still be an option but you may have to create custom attributes for this data. Not sure how advisable that is.

    Tuesday, October 23, 2018 7:08 PM
  • I think it all depends on what data needs to be where.  If the data needs to be in one of the SaaS applications, it needs to be in the SaaS application, and therefore needs to be in Azure AD.  If the SaaS applications don't need to know this piece of information, you don't need to put it in Azure AD, and can keep it on-prem.

    When I talk about Identity Management solutions with customers, I talk about the Microsoft Identity Stack.

    This consists of MIM for your on-premise synchronization and self service.  

    You have Azure AD Connect for getting on premise AD accounts in to Azure AD

    And you have the Azure AD Provisioning Service, for creating accounts in SaaS applications.

    There is no reason why you can not use MIM to connect to those SaaS applications, but if you go through Azure AD you gain a lot of really cool stuff.  So you can configure Single Sign On, Conditional Access and there is a lot of data protection you can also enable (Assuming you have the correct licences).  Making the user have a easier experience, and giving you more control over what is being accessed.

    When configuring Azure AD Connect, there is an option to create additional attributes in Azure AD.  The additional attributes can only be copies of what you have in Active Directory, but these additional parameters get created in a separate App, so you should be able to limit who can see this additional information.

    Once you have these additional attributes, when you are configuring the attribute mappings for the Azure AD Provisioning Service for the SaaS applications, these are available to flow out to the SaaS application.

    What I am not sure on, is, if you write your own App Registration, with additional attribute in, whether these would be visible to flow attributes to in Azure AD Connect.  I would try and avoid this approach though, as it means moving away from the simple deployment of Azure AD Connect, and tweaking some of the Sync Rules once the wizard is complete, which makes it a little trickier to manage.

    Wednesday, October 24, 2018 10:19 AM
  • Thanks.  We're looking at things like employee certificates and payrates, which are elements of the person but not the user object itself.  It is data that needs to go across multiple systems.  I remember that was one of the use cases for FIM back in the day.

    It's not always going to be data associated with a user account, and some of it I'd say is confidential, so I'd prefer it's not stored in AD or Azure AD

    Sunday, October 28, 2018 10:12 PM