Now that all the GDPR fuzz slowly begins to fade you might think that it's time to put your feet back on the dash and wait 'til it's all back to normal... After all, we did find all that personal data lurking in our shadow IT and we did analyze all the systems and processes handling it and just to put icing on the cake, we also carefully put together new guidelines that defines all the do's and don’ts with all that personal data. All done, right? No, not there yet. Now it's time to start to focus on the many IAM (Identity and Access Management) perspectives such as refine HR processes (onboarding, change and offboarding), implement them in your favorite IGA tool and last but not least, implement an effective and dynamic access control so that we don't have to mind all the exceptions when it comes to permissions and access to our information.
In this blog post I'll give you an outline of how to use Microsoft Active Directory Federation Services (ADFS) to provide a dynamic access control for third-party claims enabled web applications (COTS), but first a quick recap.
The benefits of a more dynamic access control based on attributes (ABAC) using XACML are all well-known to all by now (if not, read up!) and it's also clear that ABAC can provide a more effective and dynamic access control than traditional RBAC solutions. A challenge for adoption of ABAC is the fact that COTS (Commercial of The Shelf) applications all have their own access control mechanisms and adoption to ABAC by vendors is slow and often not called for by customers.
On the other hand, the adoption for SAML/OIDC has been more successful by vendors for many reasons, the cloud adoption/ease of integration for customers might be the biggest one.
So, instead of being left out in the dark, I'll give you a brief sum up on how to combine the different techniques to get the job done!
Given the great flexibility of ADFS, the first thing you start with is with creating a Custom Attribute Store, here's a good post from Microsoft - and of course, this concept will be applicable to any Identity Provider (IdP) that allows for similar extension.
When you got the plumbing all geared up, you add a PEP (Policy Enforcement Point) to it and depending on your current choice of PDP, this will look a bit different. Our favorite PDP is Axiomatics APS and they provide a nicely packaged PEP SDK for .NET which really takes the heat out of constructing the PEP. Axiomatics PDP also has a nice feature called MDP (Multi Decision Profile) which further enhances the solution by allowing the XACML request from PEP to PDP consist of a list of permissions instead of constructing and sending a XACML request per permission.
When you've constructed your Custom Attribute Store with a PEP and deployed it to ADFS it's time for the final piece, constructing a policy and deploy to your PDP.
The policy will have to handle all the user’s permissions as resources and also, of course, take contextual/environmental attributes into concern when evaluating.
I'll put it all together in a simple example:
The user starts the Claims aware COTS application and the application redirects the user to ADFS. The relying party (RP, SAML Web SSO) configuration in ADFS has a rule for issuing claims, from our own Custom Attribute Store, to the application representing security groups in Active Directory (for the sake of this example, the user is a member of 20 security groups in Active Directory).
Our PEP will then send the users 20 permissions (security groups), uniquely identified, to the PDP. The policy we made is very simple: "On weekends, users shall only be permitted to read information". Since it's Saturday in this example, the PDP will issue a DENY for all permissions, as described by our XACML policy, that allows the users to alter/write information but PERMIT for everything else.
Our Custom Attribute Store will then only return the claims that the PDP has marked with PERMIT and the final result is that the list of permissions, that is sent back to the COTS application, is applicable for the user in the actual context, only allowing for READ operations on weekends!
Surely as time goes by, our policy will mature and include more contextual attributes, for example the users network origin or the current work schedule.
Okay, I get that this is a very, very simple example but it outlines how organizations can utilize the dynamic authorization provided by ABAC and at the same time continue to use COTS applications as long as they are claims enabled.