Re: [TSEC] Where could TSec be used?

[Ersin Er <er...@gmail.com>]

On Nov 15, 2007 12:37 AM, David Jencks <da...@yahoo.com> wrote:

> 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.


The point here is that  making all those 'parts' pluggable so that Triplesec
can fill in any gaps in a security architecture. So I think before
supporting any particular external system, it should be determined what can
be delegated to external systems.


> --------------------------
> Groups?
>
> 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.



Let me state my short opinion on this long discussed topic:

Groups seem be a more structural way of classifying users where Roles seem
to be a more operational way. You do not always want to assign permissions
to users but till you may want to group them under a certain class. This
especially applies to organizational structuring. And as there are already
concepts like Groups and Roles in the industry, supporting both of them will
give different possibilities to different audiences.


References
> book: Role-Based Access Control, Second Edition David F. Ferraiolo,
> D. Richard Kuhn, Ramaswamy Chandramouli
>
> ESA products:
> http://www.bmc.com/products/products_services_detail/
> 0,,0_0_0_1602,00.html
> http://www.siemens.com/index.jsp?
> sdc_p=ft3mls4u0o1200126i1183606pHPcz3&sdc_bcpath=1180841.s_4,:1183606.s_
> 4,&sdc_sid=28883241244&
> http://www2.betasystems.com/en/products/idm/index.html
>
> thanks
> david jencks
>



-- 
Ersin Er
http://www.ersin-er.name