Advanced CAMP: BoF Summaries

2 Role-based Access Control (RBAC)

3 RBAC: What and Why? What? NIST RBAC model introduced: Role is an abstraction of a job function. Role is not a job title. Role privileges flow toward root while restrictions tend to flow toward leaf Why? Opportunity to leverage existing metadirectory or data warehouse to automatically provision roles, at least to a good degree. Potential benefits typical of integrative approach –Less overhead, faster response, uniformity, degree of automation Automates management of services provisioning for a dynamic set of users

4 RBAC: Design Implementation requirements model, data elements, components vocabulary for communities and “roles” Need flexible management of roles Number of roles necessary is dependent on department Need to manage the number carefully The closer you are to the root of the tree… –the more privileges you have Stanford has about 200 roles and the ability to delegate access privileges if user is closer to root of tree

5 RBAC: Issues Separation of Duties Can apply for travel, but cannot approve my own travel Static vs. Dynamic Roles vs. … Limitations on role assignment Limitations on session-based privileges Possible mappings of some RBAC data elements to directories Natural mappings to users, groups of users, permissions??, roles, some role hierarchies Less natural: Sessions, operation, object, permissions??

6 RBAC: Issues Department differences Physician has high access and is a leaf node in healthcare. Financial staff in leaf nodes have few permissions. Potential application of separation of duty principle to enable physicians with multiple roles to adhere to principle of need to know with regard to patient data. Short-term needs Can we “Break the Glass” and provide permissions for special functions to be verified or audited later? Permissions can be allowed while flagging it for examination later.

7 RBAC: Issues Design considerations How much should be automated and how much should be left in its current state? What is good enough? Maybe ignore exceptions and consider an 80 or 90% solution as a start.

8 Management of Identity

9 Management of Identity: Key Issues Liability Giving accounts w/out verified identity create risk. Issuing entity could be liable for misuse of account. How do you accurately identify any entity accessing your services? How do you verify that identity and who is responsible? Face to face Through documentation Sponsorship Where is the reconciliation of Identity? It varies. –In the registry –In data management How do you get correct information, how do you verify it’s correct, how do you keep it correct? Use SSN’s as temporary password to verify correctly entered Send Birthday mail soliciting updated info Set mandatory renewals on accounts

10 Directories are bracketed on both ends by identity Key underpinning of directory services Layers on top of directory services Surprise! Often IT departments are managing identity Results from complexity of coordination between data owners. Need Rules and definitions in common between different parts of the organization Buy-in from key parties supplying identity data. Sharing identities (with multiple roles) among multiple domains is a multiple campus issue Management of Identity: Insights

11 Affiliated Directories

12 Affiliated Directories: Potential Problem Space Directories joining data across more than one administrative domain Super-set or intersection of identities; "identity math" Asserting attributes on behalf of another entity; three-tier Updating and refreshing data in affiliated directories automatically

13 Affiliated Directories: Necessary Functionality Common language for exchanging information Identity management Authorization (Interrealm RBAC?) Attribute metadata underlying trust fabric

14 Affiliated Directories: Similarities to Current Systems Metadirectories Liberty Alliance 1.0 Identity Matching Generalized SHAR/AA Interaction Useful to many other applications once functional

15 Affiliated Directories: Possible Scenarios (yet to be adopted): Mapping There is a commObject URI in my enterprise directory that links me to a commObject in the ViDe environment. The video client wants to recognize that the two objects are linked in that direction. Authorization How do we represent and trust an attribute placed in Brown's directory that Steven Carmody is a member of MACE? How is this asserted, validated, and understood?

16 Affiliated Directories: Possible Scenarios (cont.) Pull I mirror an identity of Michael Gettes in my local directory with additional GRIDperson information. How can I know how volatile this information is, or how likely it is to have been changed? Push If I change my name to Bob, how can I ensure that anyone else maintaining a version of my identity learns this?