LDAP vs SAML Authorization

Question

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 1

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).

Answer 2

Building on Eugenio Pace's response, and in particular following this paragraph:

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.

What Eugenio refers to here is ABAC - attribute-based access control. SAML does not do that. To achieve ABAC, you need XACML. Both SAML and XACML are standards defined by OASIS and that interoperate. With XACML you can define attribute-based rules. For instance we could revisit your example and write a rule as follows:

• A user with the role==administrator can do the action==update on a resource of type==printer if and only if the department of the user == the department of the printer.

You can read more on XACML on ABAC at these reference sites:

• NIST's site on ABAC.
• OASIS XACML Technical Committee