LDAP vs SAML Authorization
I'm currently investigating moving an asset tracking system from LDAP to SAML. There are two main areas where our software currently uses LDAP. The first is authentication. In order to access the system today you need to successfully authenticate with LDAP and be a member of a specified LDAP group. That part is fairly simple to move over to SAML. We've utilized a library to handle most of the dirty work. And on the IDP we can add a claim to authorize the user. But our second use of LDAP is throwing me for a loop.
Today, each asset that we maintain has the ability to be linked to a username. For example, a particular printer may belong to 'someuser'. One of the options our software gives the administrator is to view/interact with assets based on LDAP user groups. So as an administrator, I may want to update all the printers that are owned by people in a particular department. To accomplish this, the administrator would create a rule scoped to the LDAP group 'departmentInQuestion'. Our software would then use a service account to connect to LDAP, create a query to see which users from our system are in 'departmentInQuestion', execute that and use the results to determine which assets should get the update.
So far from my searching I have not been able to find a SAML workflow analogous to this. It appears the only opportunity we have to asses 'someuser' is when they authenticate and we get access to their claims. But in our workflow 'someuser' may never authenticate with us. It's almost as if we're using authorizing a user on behalf of the service account. Is there an existing workflow that I've overlooked during my exploration? Are there any other technologies that support authorization in this manner?
Thanks for any input!
Answer
SAML is like a passport or a visa. It has (trusted) information about you that can be used to know about you (e.g. your name, DOB) and infer what you can access (e.g. entrance to a country). You can use properties in the token to query other systems about additional information you might be associated with (e.g. your bank statement).
So, analogously, SAML is typically used to authenticate users to a system (once you trust it's origin), but there're no provisions for managing user profiles, or 'resources'.
Authorization decisions, if any, are often made based on the attributes associated with the user (e.g. the group he belongs to) and conveyed in claims in the security token.
Perhaps the 1st questions to answer is why you want to move away from LDAP and thinking about SAML. Is it because you want to accept users logging in with their own credentials? Is it because you want to get rid of the LDAP server altogether
You could perfectly well keep your LDAP server for managing resources associated with users, and authenticate users somewhere else. This is what you have now. You would correlate users "outside" and "inside" via a common attribute (e.g. a username, or some ID).
If you want to get rid of LDAP all together, then you'd need someplace else to store that information (e.g. your app database).