When collecting requirements for an IAM solution we associate actions with various ways of categorising users – in other words, we are mapping “form” to “function”. When designing the IAM Solution, however, we need to provide a layer of separation between the two. The best way to illustrate why is with a real-life example.
For a university we were providing two self-service password reset OTP options: staff would get their OTP sent to their registered mobile phone number, and students would get it to sent to their registered home email address. Initially the design was to create a “Staff SSPR Policy” and a “Student SSPR Policy” and tie them directly to the data source we got the initial identity record from – either the HR system or the Student Register.
I insisted on this being changed to the “SMS SSPR Policy” and the “Email SSPR Policy” – ie based on function, and not on the expected type of user who would be on the receiving end. Which category you fell into was based on an attribute “SSPR Type”, and that attribute was set based on the identity source.
So no actual functional difference then? Well not initially – but here’s an entirely plausible future scenario:
- First the university decides all PhD students should get SMS SSPR. The easiest way to get them into the policy is to flag them as “Staff”. There doesn’t seem to be any other adverse impact so that’s what happens.
- Later the university decides that all Honours students, and all students working as tutors and lab assistants should aso get SMS. Again they get flagged as “Staff”.
- Later still an application is integrated into the IAM solution that only staff get. Entirely sensibly the “Staff” flag is used as a decider – but what’s this? Why did all these students end up in the application??
By separating form from function in the first instance we need only have changed how the value of “SSPR Type” got set. Simple, flexible, and no weird after effects.
I think this approach is particularly important in IAM Solutions because, depite all efforts to keep them simple, they’re not. They always involve a variety of components to interface with end systems, load and transform data, express provisioning logic and provide access management. There is always a degree of custom coding and scripting. There are usually a few different ways a particular requirement could be implemented. Coming in to an existing IAM solution and trying to understand what it’s doing is difficult enough without also having to know a whole lot of history about how things got that way. Separating form from function at least helps by clearly identifying what something is or what something does. Try not to mix them up.
