directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject [TSEC] Where could TSec be used?
Date Wed, 14 Nov 2007 22:37:29 GMT
It turns out the NIST RBAC  guys have written a book, and reading it  
has broadened my thinking about where the RBAC aspects of TSec might  
be used.  Here's my current thinking on this subject.

1. Basic architecture
1.1 Who administers the users?
1.1.1 TSec.  TSec admin tools are used for adding and removing users,  
and uses and user-role associations (whether or not groups are in  
between) are maintained in tsec-controlled data stores such as apacheds.
1.1.2 Something else such as MS ActiveDirectory.  Here tsec will need  
to maintain some kind of (external)user-role or (external) group-role  
association but will not  directly manage users.
1.1.3 (may not be plausible) User data is in e.g. AD but TSec admin  
tools administer it.  I'm going to ignore this case for now.

1.2  Who determines authorization?
1.2.1 TSec.  TSec code is used to evaluate authorization decisions  
directly whenever such a decision is needed.  Examples of this are  
TSec as a JACC provider or a potential TSec linux PAM module.
1.2.2 Something else.  For instance a normal linux PAM, MS AzMan, or  
a mainframe security system

2. We can combine the answers to these question to produce some  
scenarios (using AD to stand in for any external system):

2.1 Standalone TSec. TSec manages the users, roles, permissions, and  
determines all authorization decisions.  For instance, TSec JACC with  
users administered via TSec.  This is what my sandbox tsec aims for.   
It's possible for me to imagine writing a PAM module and running  
linux os security off of tsec in this scenario, but I have no idea if  
this would be practical.

2.2. AD + TSec.  Users are maintained in an external system such as  
MS AD, but TSec is used to administer user or group-role associations  
and role-permission associations.  TSec is used to make authorization  
decisions.  For instance users might be in AD but we are running  
javaee apps using JACC.  If I understand correctly Alex needs to get  
this scenario working.

2.3. TSec + AD/Linux/RDBMS/Mainframe.  Users, roles, permissions,  
user-role assignments, and role-permission assignments are all  
maintained in TSec.  There's a provisioning system that translates  
the authorization information into target system format and  
propagates changes from TSec to the target system.  For instance TSec  
could maintain users, roles, and permissions, and provision an AD  
system by representing AD groups as TSec permissions.  The user-role- 
permission chain of associations would get mapped to AD group  
membership.  Another possible mapping would map TSec roles to AD  
groups and TSec permissions to AD permissions (however they may be  
represented, I don't know).  There seem to be a fair number of large  
expensive commercial ESA (Enterprise Security Administration)  
products that do this.

2.4. AD + TSec + External.  An external system (AD) is used to  
administer users (and maybe groups), tsec is used to administer user- 
role and group-role associations, role-role associations, and role- 
permission associations.  Changes are propagated into an external   
system (RDBMS? Linux? Apache web server?) which makes the  
authorization decisions.  I don't feel a burning need to pursue this  
scenario right now but see that it might be useful.


One thing I noticed looking at the the 2.3 ESA products is that they   
very definitely  associate users and roles and typically regard  
groups as something like a permission that's associated with a role.  
This suggests to me that for 1.1.1 TSec installations the model that  
follows common industry practice would be to associate users and  
roles and not try to put groups in between.  This would correspond to  
2.1 and 2.3 scenarios.  For 1.1.2 installations some kind of group- 
role association glue is likely to be needed in the tsec data storage  
although I think its conceivable if unlikely that someone would  
ignore external groups and have only user-role associations.

book: Role-Based Access Control, Second Edition David F. Ferraiolo,  
D. Richard Kuhn, Ramaswamy Chandramouli

ESA products: 

david jencks

View raw message