RBAC Profile Questions

[Darran Rolls <darran.rolls@sailpoint.com>]

Title: RBAC Profile Questions

As discussed during last weeks call, I wanted to put a few questions to the list for comment.   Having read through the draft 3.0 RBAC profile, I’m left with some (possibly simple) questions and a proposal for your consideration.  Some of these comments/items my be founded in my lack of historical context and (likely) my fairly limited experience implementing the core specification.  Regardless, here goes:

Addressing SoD Rules
 
Regarding static & dynamic SoD rules being dropped for 3.0.  I believe that SoD rules are essential for the conceptual operations of a Role Enablement Authority, and would like the committee to consider adding at least static rules to the draft spec.  I do agree with Hal’s comment that this TC is not responsible for defining a specific protocol for the exchange of dynamic SoD decisions.  I also appreciate that simple exclusions rules are not complex to define as part of a generic policy(Set) somewhere else in the spec (constraints, or some context somewhere).  However, it seems (to me) that addressing recommendations on how and where SoD should be defined is a critical element of a profile for RBAC.  I would be happy to help work on adding this if the committee agrees we have the time and the inclination to do so.

Adding more information and examples

In general, I’m of the opinion that the “role” of the REA is much under state in the overall model. I get that in theory, an REA is really just a specialized PIP, but in reality I believe it is a lot more than that and likely warrants some beefing-up in the specification.  The current draft profile  gives “no fixed form” for the REA policies.  This leaves much to chance in implementation.  Living in the REA world, I can say with confidence that the complexities of defining an “operational context” for REA assignment decisions has gotten pretty complex these days.  We are now driving  role (and hence attribute and entitlement) assignment based upon complex rules derived from multiple subject attributes. Sure this all sounds like very vanilla policy definition stuff, but being able to express, exchange, merge and interoperate these rules will become essential when complex decisions are hung of key identity/role assignment results.  From a compliance and governance perspective alone, it seems essential that one should be able to ask the REA to share that information/policy with other entities in the model.  Again, I would be happy to help work/propose something here.

More PDP -> REA Exchange Models

I’m interested to know if anyone has given any thought to how the PDP -> REA model might fit or otherwise be re-used within a Higgins IdAS model.  The spec currently lists a SAML assertion and an LDAP exchange model, would anyone be interesting in addressing how this might interoperate with a Higgins idAS context handler that was functioning as an REA,, or is this way off base?

Thanks
Darran

-- 
CTO
SailPoint Technologies
http://www.sailpoint.com