Roles are turning into the hot topic this year, and with Dave Kearns, Dave Shea, Ed Zhou and Robert Ciampa in just the past couple of weeks, I thought I’d better pitch in with my 2p worth, given this is an area I’ve spent a lot of time thinking about (and writing about [PDF, 260k], I thought I’d write a little more.

When thinking about Roles and how they relate to privileges, I’ve always found it much easier to think of everything as a role. And I do mean everything. A ‘group’ is a role, it just happens to have a lot of other roles attached to it. Specific access privileges (such as being able to print to a specific printer) are also roles.

However perhaps the most critical aspect in this thinking is that there is absolutely no inheritance of permissions at any stage. Whilst there is a convincing simulation of inheritance, at no time does an account derive permission to do something simply because of that account’s location within the hierarchy, or because of membership in a group, where the group has the permissions.

Rather, by converting more traditional Groups to Roles, and explicitly linking a group of individual roles to the Group role, you can simulate groups-based inheritance (everyone who is given the Group role gets all the roles associated with that group) without having to worry about inheritance.

However the key to making this work properly is in having a fully implemented provisioning service which reprovisions all rights, roles, permissions across all provisioned systems every time an account has it’s roles changed. This avoids problems with having to worry about retained rights, inherited rights, or even conflicting rights. To make comment on something Ed Zou said:

A simple change can often have multiple effects. For example, when a person is relocated to east coast should he still be managing the customers at west coast? Should he stay on the revenue processing team? Often time these are managed on separate systems.

If a full roles-based system is implemented, this problem goes away. The person working on the West Coast has a set of West Coast roles. If they move to the East Coast, they get a set of East Coast roles instead of the West Coast roles. If they need access to anything from their old set of roles, these are added separately. The provisioning system then resets all the necessary permissions in whatever systems need to be set. And you’re done.

If you approach Roles in this manner, you can create ‘Role Groups’ that are closely aligned with business requirements or business roles. There is perhaps a greater need for up-front effort in creating all the initial low level roles that provide permissions-based access to various systems, and also require the implementation of fixed procedures for the implementation of new systems so that the relevant low-level roles are created to match the new permissions that need to be provisioned in the new system, but once this is done these roles can be grouped as needed.

By also implementing a ’smart’ provisioning system that can work out if a certain set of permissions has already been provisioned, then there doesn’t need to be uniqueness between role sets either - one instance of a role simply replaces another instance of the same role. You avoid problems with inheritance of permissions, you can change roles as needed, and through automatic reprovisioning, addition or deletion of roles translates almost immediately to a change of permissions.

More later.

James’ thoughts on bloggers and federated identity has been one of my own followup subjects for early this year, but it seems SuperPat has beaten me to it, prompting me to actually write something.

I’m going to only touch on a few of James’ points (coloured by my reading of SuperPat and others, certainly) though:

Identity Bloggers pretend that notions such as Sarbanes Oxley don’t exist (or at least never mention them). Do they think that federations also need the notion of attestation? If so, don’t you think this will become an impediment to corporate adoption of federated identity for many verticals?

I guess it depends which blogger you read. Whilst I certainly don’t talk much about Sarbanes Oxley, it might be because I have to worry more about Basel II. That said, the concept of the necessary audit trails and documentation needed for this type of compliance is something that has coloured the entire Identity Management project I’ve been working on, and has been a cornerstone of the design. It’s not that I’m not talking about Sarbanes Oxley, it’s that to me it’s only another piece in the puzzle.

SAML 2.0 is a good move to increase interoperability and should be implemented in all security oriented products. Maybe you can tell us why within the enterprise we should use SAML 2.0 between say Active Directory and RACF vs. sticking with tried and true approaches such as Kerberos?

Because we’re replacing the inter-application communication channels (in a lot of cases) with a mediator and access control manager. But where existing secure communications channels exist that are outside the bounds of managing Identity, then we have no reason to touch or change them.

Do you think that enterprises are well-served by consolidating identity stores vs keeping them spread all over the place and doing SAML? If consolidation is a good thing, why wouldn’t it be a good idea to consolidate identity within Active Directory?

There’s been a lot of discussion about consolidating identity stores, with arguments both for and against enterprise directories (I’ll dig out the links later). Of course, the question )to me at least) is more about whether it’s a good idea to consolidate identity stores or identities within stores. A small difference sure, but one means putting everything in the same place, the other means making sure the identities held in different places all match up. Personally I like the idea of a virtualised meta directory of identity, where there is a central identity store that only exists as a virtual entity, and is made up of information stored in a lot of different authoritative sources.

If you want corporations to embrace the notion of federated identity, wouldn’t it require more than simple “look at me” interoperability demos and for all the vendors in this space to create some publicly available notion of “reference architecture” above and beyond what exists in Project Liberty?

The Shibboleth project is already in use, as is AthensDA, both federation services. In my current project though we need to (and will be) supporting both of these federation services, as well as Liberty and most likely JANET-LIN. We’ll also be supporting as many other types of federation as possible. As a research organisation one of our aims is to ensure that collaboration between organisations and individuals is made easier, something that a federated identity service can assist greatly with.

Any thoughts on how federated identity can integrate with Digital Rights Management?

Our approach is that federated identity can be used to enahnce access to any DRM system that we may need to put in place, especially in relation to digital content archives. But then working in an educational environment is slightly different to working in the corporate world :) (I was looking into a European scheme late last year that aimed to allow greater community access to digital content (including DRMed content) through the use of federation services. Certainly an interesting project as it crosses several disciplines, not just Federated Identity services).

How come pretty much all of the identity bloggers don’t support trackback in their blogs?

I do!

Technorati Tags: Identity, Digital Identity, Federated Identity, Shibboleth, Liberty Alliance, AthensDA, Sun, SuperPat

SAP have entered the Identity Management sphere with an announcement of a global strategic alliance to deliver a standards-based identity management solution.

The solution will be delivered through SAPs Netweaver platform, and is based on Siemens Identity Management solution called HiPath SIcurity DirX Identity. The alliance aims to allow organisations using SAP to integrate with their existing deployments and centralise the management of access to IT systems.

This is interesting, as it seems to indicate that SAP and Siemens will be immediately deploying a full RBAC implementation based on SAP’s internal job role specification:

With the integrated solution, each user is represented by a unique digital identity and assigned access privileges to applications and systems based on their job role in the organization. Employees are able to easily and transparently access all systems and applications needed to support their job roles without having to worry about the underlying infrastructure.

The user’s privileges are centrally maintained, continuously updated to reflect changes in the organization, automatically communicated across all relevant systems and withdrawn immediately if necessary.

If you’re concerned about which standards are being supported, check out this PDF about it.

Technorati Tags: Digital Identity, Identity, SAP, Netweaver, Siemens, Roles, RBAC, mySAP

Radovan Semančík has been posting a series of articles on Identity Management, and the latest is a discussion of different approcahes to role capture and definition.

You will soon realize, that you have two or three times the number of roles than the number of employees. Now, it looks like you would spend all your effort on role-maintenance instead of employee-maintenance - the role system as just as dynamic as is the employee base. That’s pretty different from the solution as it was described by sales people: “you will just assign an employee to the role and that’s it”. But, there are ways out of this. At least partially.

Technorati Tags: Identity, Digital Identity, Roles Based Access Control, RBAC

When I first started researching Roles Based Access Control (RBAC) in detail at the tail end of last year, I spent an enormous amount of time on the web reading through transcripts and papers from academics and commercial organisations. Those that I found interesting or added to what I knew about RBAC were printed out for reference. I thought it was about time I went through the pile of documents I kept and listed them. So here it is: my primer to Roles Based Access Control theory and practice.

1994

Access Rights Administration in Role-Based Security Systems

1996

Roles Versus Groups (PDF)

1997

Observations On The Real-World Implementation Of Role-Based Access Control (PDF, via NIST)

1998

Towards a more complete model of role
Role-based access control in Java

1999

Integrating Policy-Driven Role Based Access Control with the Common Data Security Architecture
The role graph model and conflict of interest
Migrating to role-based access control
The Uses of Role Hierarchies in Access Control (PDF)
Role-Based Access Control on the Web (PDF)

2000

Injecting RBAC to Secure a Web-based Workflow System
Application of XML tools for enterprise-wide RBAC implementation tasks
Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Control Policies
The role-based access control system of a European bank

2001

An Argument for the Role-Based Access Control Model (PDF)
A model of OASIS role-based access control and its support for active security
RBAC Policies In XML For X.509 Based Privilege Management (PDF, Salford University)

2002

RBAC Policies In Xml For X.509 Based Privilege Management (PDF, Salford University)
Implementing Role Based Access Controls Using X.509 Attributes (PDF, Salford University)
The PERMIS X.509 Role Based Privilege Management Infrastructure (PDF, Salford University)

2003

Role Based Access Control (NIST)

2004

SSCSD SD 541, June 2004 (PDF, US Navy, via NIST)
Using UML To Visualize Role-Based Access Control Constraints (PDF)

2005

Roles: Burton Group Reference Architecture Technical Position (login required)

On top of these documents, this page on the ACM website contains an archive of links to all the papers given at previous ACM Workshops on Role-Based Access Control (some of which are explicitly linked above). The conferences are now sponsored by the ACM Special Interest Group on Security, Audit and Control (SIGSAC).

Enjoy!

Technorati Tags: RBAC, Roles Based Access Control, XML, X.509, Java, Identity Management, Digital Identity, Enterprise Architecture, University of Salford

It’s been one of those months where a lot of information about a lot of initiatives has been released in a lot of areas, but it’s not until you combine them that something really interesting almost appears.

Let’s talk about web2.0 and AJAX, and some of the things that are now appearing. There’s Writely for word processing, Numsum for spreadsheets, Meebo for chatting, and lastly Netvibes, which, while not being new (or relatively new, and Microsoft have their own version), has provided the catalyst to what I’ve been thinking about.

I’ve been thinking about personalisation, and more importantly, portable personalisation.

(more…)

I’ve been remiss: A couple of days ago Robin mentioned some informative articles in Information Age (free copies gratefully accepted). One of the comments Robin made caught my attention, amongst all the other worthy thoughts:

For instance, a couple of his contributors note that HR departments are often the point at which information about a user intersects with information about IT resources (particularly in role-based setups, I would suggest), but then go on to note that the HR department should not necessarily ‘own‘ the digital identities as a result. I would go further and suggest that responsibility, accountability and even liability for digital identities and their use should rest with an employee‘s business unit - even if, as is often the case, the ‘definitive source‘ of information about who is an employee does indeed reside in an HR repository.

We’ve been thinking about this a lot in our project, and rapidly came to the decision that Delegated Administration was a primary function of any widely implemented Identity Management project.

If you look at the Powerpoint demonstration (Warning! It’s 11Mb!) we created about our Identity Management Proof of Concept you can see the concept of Delegated Administration demonstrated as implemented in the PoC.

The basic idea behind this is that whilst the HR function retains ownership of the people recorded in their systems, the IT function (or a department within the IT function) takes responsibility and ownership for creating the framework for rights delegation. And each individual department then takes ownership of, and responsibility for managing what rights each individual within that department has.

By consolidating the Identity Management service with the Access Management and Roles services, you can actually make use (I’m going to use the word ‘leverage’ - you can all call me names later) of the Roles system to delegate permission to change Identity information within a limited scope.

With one of the most expensive parts of IT administration being managing and changing user access rights, in large organisations it’s only logical to devolve these rights to individual business units. It’s empowering (yes, yes, call me more names), and it also reduces the administrative overhead on the IT function to a more abstract level.

To requote Robin:

I would go further and suggest that responsibility, accountability and even liability for digital identities and their use should rest with an employee‘s business unit - even if, as is often the case, the ‘definitive source‘ of information about who is an employee does indeed reside in an HR repository.

This is the route we are taking.

Update: We did actually post a paper discussing the problems of Identity and Delegated Administration as part of the Proof of Concept papers.

Technorati Tags: Identity Management, Identity, Delegated Administration, Digital Identity, Roles Based Access Control, RBAC, Access Management

I’m going to echo one of the comments made on this post by Pat Patterson, Sun’s Access Manager technical architect:

Talk about obtaining more knowledge via blogs rather than from product docs ;-)

The post, titled What is Federation? goes into detail about federation and federated services, touching briefly on Liberty, SAML and even Shibboleth. Go read Pat’s post, or start with Rohan Pinto’s original post that led to Pat’s comments.

Technorati Tags: federation, federated identity, identity, digital identity

I’ve been thinking more about Workflows as Roles in the past few days. In my original White Paper (280k PDF) on Roles Based Access Control I introduced the basic data model for Roles and Role Groups as show here:

Since then I have been giving it more thought, and trying to combine this data model with the concept of allowing a workflow to be the end definition of a role. (more…)

I’ve been thinking a lot about Roles Based Access Control recently as part of the work I’m doing for Salford. I wrote a paper (280k PDF) about it recently. One thing that I’ve been thinking about is how to represent ACLs or access permissions to hardware within role definitions.

It struck me that, given we’re implementing a system that also includes provisioning services and a workflow engine, that rather than defining low level roles (for example permission to print to a specific printer) in terms of a role definition, instead we can define the role in terms of the workflow needed to provision the access the role controls. (more…)