A feature of ComPlus implemented in Win2K and above. The infrastructure centers on the concept of a role, which is an application-wide group of users. Each COM+ application has its own set of roles named like Doctors, Nurses, etc. Roles are stored in the COM+ Catalog. The Administrator uses the Component Services snap-in to add the roles to the application. Users are assigned roles.

The easiest way to use RoleBasedSecurity is simply to refuse to allow any user who is not assigned to a particular role to create an object or call a method. COM+ allows an administrator to specify which components, interfaces, and methods can be accessed by members of which roles. 

-- sg

''How does this differ from group-based security. Would it be the same as having groups Doctors, Nurses etc., and putting them in groups. Is the distinction that these are system-wide rather than application-wide?''
 
Roles are part of the application-specific configuration, and are independent of system-wide security groups.

''Application-specific groups? Seems to be slitting hairs to me.''

----
RoleBasedSecurity is also a feature of the EJB component model. EnterpriseJavaBeans Specification, v1.1, Section 15.3: 'It is important to keep in mind that the security roles are used to define the logical security view of an application. They should not be confused with the user groups, users, principals, and other concepts that exist in the target enterprise's operational environment.' (This might go some way to answering the question above. It's partly about names - groups are used for system admin, not application admin.)

There's a good description of the EJB model here: http://www.jboss.org/documentation/HTML/ch09s02.html. 

The EJB model has an interesting delineation of how roles are used: an EJB creator does not (generally) address security concerns because they don't know what use is to be made of their component. An application assembler bundles components and describes security declaratively, defining roles and what methods/beans they have access to. An administrator then assigns users to roles, after the application has been deployed. Seeing it this way, it makes sense that you can't allocate permissions to individual users. Also note that the system admin has no say in defining the roles - that's the application assemblers job.

''IOW, in practice security probably doesn't get addressed at all, because the application assembler will usually have their hands full just getting the components to work together, and isn't given any help with security. -- DavidSarahHopwood''

I'm not sure if this is quite the same as what Sam's describing - 'The Administrator uses the Component Services snap-in to add the roles to the application' would suggest to me that the roles are not distributed with the application? Sam, did you mean 'add the users to the roles?' looking at my own Component Services snap-in, I can see the option to do that, but not how to add roles. If that's what was meant, then it looks much the same as EJB. -- BrianEwins

Roles can be, but are not required to be, distributed along with the application. The Component Services "Export" operation gives you the option.  Distributing the security configuration may be a security breach in some circumstances.

See also RoleBasedAccessControl.

Contrast with CapabilitySystem, CapabilitySecurityModel.

----
CategorySecurity CategorySecurityModel CategoryGlossary CategoryDefinition