Access Control Advice
In a recent project for a Fortune 100 company I was asked to be the subject matter expert on the identity integration aspects. The goal was to connect a content management system (Drupal) to the company's SAML Identity Provider.
During an initial planning call I asked, "How do you want to control access to the site?" My reason for asking this was to make the distinction between authentication and authorization. Typically when I ask the question people will answer, "With SAML.", which is my cue to educate them about the difference between authentication (i.e., Are you really who you claim to be?) and authorization (i.e., What are you allowed to see or do?).
In a SAMLized environment, and especially in a federated environment with multiple identity providers, it is important to distinguish between authentication and authorization. Conflating the two can cause numerous problems.
Shortsightedness can cause us to conflate authentication and authorization and when that error makes its way into our system designed it can tie our hands in unexpected ways. For instance, making it difficult to increase the potential user population by connecting additional identity providers.
We also have to be careful about how we use attributes from identity providers in authorization decisions, especially when there are multiple identity providers. It's important to understand how the attributes are managed and which assumptions we can safely make about their meanings.
This is where research is often necessary. I have experienced situations with clients where it turned out the attribute they wanted to use wasn't managed by the right group of people and wasn't meaningful in the context of the project we were working on. It's always good to find this out early so that appropriate steps can be taken to get meaningful data.
Once we understand the difference between authentication and authorization and once we understand the data we plan to use for authorization an important next step is to decide how will we use the data to make authorization decisions.
Let's imagine a system that uses a single SAML Identity Provider for authentication and in the attributes the identity provider is publishing an attribute with group information. How should a consuming application use the group information? It's been my experience that consuming applications should use this type of information as advice in the decision making, not as the decision itself. This is especially true if the application and identity provider are run by different groups and/or additional identity providers will be added in the future.
In order to abstract one or more identity attributes from the authorization mechanism some type of abstraction code (middleware) should be used. For example, the simplesamlphp_auth module supports the ability to assign Drupal roles based on attribute values.
Thinking of identity attributes and group affiliations as advice in the authorization process, rather than the decisions, has saved my clients from major headaches as they grow there SAMLized environments.