You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Eric Dobbs <er...@dobbse.net> on 2002/02/08 02:55:40 UTC
Re: Security Changes (2 of 3) - JAAS Principals described
Hi All
There's a lot of confusion around Principals. Let me
see if I can clear it up. If I understand JAAS
correctly, Principals come into play in five aspects
of the authorization and authentication.
First, and most important for Turbine, Principals are
where Roles and Groups would be implemented.
Second, and also important for Turbine, Permissions are
connected to Principals, not directly to subjects.
Third, the Subject would have many Principals, one of
which serves as the userid.
Fourth, Principals come into play in Pluggable
Authentication Modules (PAM). This allows an
administrator of an application to choose their own
authentication technologies and policies. (LDAP, DB,
ActiveDirectory, Kerberos,...)
Fifth, Principals are used to enable a Subject to login
once and be granted access to many applications.
That's what I understand about the JAAS Principals.
The harder I look at the JAAS terminology and model,
the more it makes sense to me. That's why I keep
pushing it. I think it is fairly well thought out and
worth trying to understand.
Hopefully a picture will also help clarify:
+-------+ 1 N +---------+ 1 N +----------+
|Subject+-------+Principal+----------+Permission|
+-------+ +----+----+ +----------+
|
+-----------+---------+
| | |
+--+---+ +--+--+ +-+--+
|UserId| |Group| |Role|
+------+ +-----+ +----+
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes (2 of 3) - JAAS Principals described
Posted by Eric Dobbs <er...@dobbse.net>.
On Tuesday, February 12, 2002, at 10:25 AM, Chris Holman wrote:
> [Eric Dobbs Wrote]
>> grant
>> codebase TURBINE_GROUP
>> Principal TURBINE_ROLE {
>> permission TURBINE_PERMISSION;
>> }
>
> Seems a little convoluted and inflexible ... maybe thats just me?
> I was hoping that the Principal IF would be more adaptable!
I agree. My main point was to map the concepts of
JAAS codebase and Turbine 2 TURBINE_GROUP
> The idea of a Principal Interface is quite nice though. It allows
> the policy to be relitively simple. It just doesnt seem to
> provide the sophistication required by the Turbine style
> permissions model.
I haven't given this very much thought, but there
might be an instructive example in O'Reilly's
_Java_Security_. Starting on p. 372 there is a
description of a custom implementation of JAAS
Policy class to enable user specific file
permissions. That might provide a better option
than my codebase->TURBINE_GROUP mapping.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (2 of 3) - JAAS Principals described
Posted by Chris Holman <ch...@owl.co.uk>.
[Eric Dobbs Wrote]
> grant
> codebase TURBINE_GROUP
> Principal TURBINE_ROLE {
> permission TURBINE_PERMISSION;
> }
Seems a little convoluted and inflexible ... maybe thats just me?
I was hoping that the Principal IF would be more adaptable!
>
> I think Turbine may need custom JAAS implementations, but I'm
> not sure the one you've proposed is exactly right.
No surprise there :-)
> I should also add, in case I haven't already made this clear,
> that what I've been proposing for the new security model is not
> a JAAS implementation. I'm trying to learn something from JAAS
> but not necessarily follow it completely.
I understood this, just wanted to see what the shortfalls of JAAS
are for myself. My attempts so far have led me to the same
conclusion.
The idea of a Principal Interface is quite nice though. It allows
the policy to be relitively simple. It just doesnt seem to
provide the sophistication required by the Turbine style
permissions model.
Chris
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes (2 of 3) - JAAS Principals described
Posted by Eric Dobbs <er...@dobbse.net>.
On Monday, February 11, 2002, at 10:56 AM, Chris Holman wrote:
> Examples from Sun indicate that the concept of Groups and Roles should
> be
> implemented using the Principal Interface.
yup.
> Well, I think it is reasonable to expect JAAS to be capable of
> implementing
> the current Turbine permissions model, so I thought I'd give it a go.
> BUT, how would I implement the (semi)complex relationship between
> Turbine
> users, groups and roles? It doesn't seem possible with the default
> implementation of JAAS.
I think that the TURBINE_GROUP corresponds roughly to the Java
Security notion of a CodeBase. It would not be modeled as a
Principal. If I were writing a JAAS Policy it might look like
this:
grant
codebase TURBINE_GROUP
Principal TURBINE_ROLE {
permission TURBINE_PERMISSION;
}
I think Turbine may need custom JAAS implementations, but I'm
not sure the one you've proposed is exactly right.
I should also add, in case I haven't already made this clear,
that what I've been proposing for the new security model is not
a JAAS implementation. I'm trying to learn something from JAAS
but not necessarily follow it completely.
Please don't let that discourage you from trying to get JAAS to
implement Turbine2 permissions. 8^)
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (2 of 3) - JAAS Principals described
Posted by Chris Holman <ch...@owl.co.uk>.
[James Taylor Wrote]
> As for the real question, I don't see group or role as being principles
> really. Group / role exist in the underlying JAAS provider as a means of
> associated subjects to permissions, which is why they don't need to
> exist in the interfaces.
Examples from Sun indicate that the concept of Groups and Roles should be
implemented using the Principal Interface.
My suggestion wasnt to implement Roles and Groups in the interface but to
make Principal a container of Principals, like this
http://java.sun.com/j2se/1.4/docs/api/java/security/acl/Group.html
Why? I hear you ask.
Well, I think it is reasonable to expect JAAS to be capable of implementing
the current Turbine permissions model, so I thought I'd give it a go.
BUT, how would I implement the (semi)complex relationship between Turbine
users, groups and roles? It doesn't seem possible with the default
implementation of JAAS.
I was suggesting that extending the Principals interface, to contain
Principals or Principal pairs, is one way of enabling JAAS to implement the
Turbine permissions model.
Chris
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (2 of 3) - JAAS Principals described
Posted by James Taylor <jt...@4lane.com>.
> Users contain Groups contain Roles contain Permissions
I believe that this is an incorrect (though common) interpretation of
the classic turbine security model. I think this should be
* Roles contain permissions.
* ( User, Group ) pairs have roles.
The second piece could also be read:
Users have specific roles in specific groups.
>>From the turbine security how-to:
Group is a something that a User would want to do something in. In
the Turbine mailing lists it has often been described in the same
way as a project. In a project you have fulfill a role, however a
User doesnt "belong" to a project they merely have a role in that
project ( or group ). In this manner too a User can have many Roles
within the one Group. For instance a User may have the Role
Developer in the Group, but may also have the Role of Administrator
as well.
As for the real question, I don't see group or role as being principles
really. Group / role exist in the underlying JAAS provider as a means of
associated subjects to permissions, which is why they don't need to
exist in the interfaces.
--
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (2 of 3) - JAAS Principals described
Posted by Chris Holman <ch...@owl.co.uk>.
I've been writing up a comparison of JAAS and Turbine and I've hit a
problem with JAAS.
Eric's nice diagram below shows that JAAS, in its current form,
cannot be used to implement the existing Turbine Permissions
Model i.e.
Users contain Groups contain Roles contain Permissions
The diagram from JAAS below shows:
Subjects(Users) contain Principals contain Permissions
Since the Principal interface would be used to define
Groups and Roles, and Principals cannot contain Principals,
I have to surmise that the default implementation of JAAS
cannot implement the existing Turbine Permissions Model.
Anybody know differently? Have I missed something?
The Principal interface could be extended to include a collection of
references to other Principals. But this would require the
Policy interface to be extended to cope with Principals as containers.
I think this is feasible?
PS: I'll post the JAAS analysis when its complete.
Chris
> -----Original Message-----
> From: Eric Dobbs [mailto:eric@dobbse.net]
> Sent: 08 February 2002 01:56
> To: Turbine Developers List
> Subject: Re: Security Changes (2 of 3) - JAAS Principals described
>
...
> The harder I look at the JAAS terminology and model,
> the more it makes sense to me. That's why I keep
> pushing it. I think it is fairly well thought out and
> worth trying to understand.
>
> Hopefully a picture will also help clarify:
>
> +-------+ 1 N +---------+ 1 N +----------+
> |Subject+-------+Principal+----------+Permission|
> +-------+ +----+----+ +----------+
> |
> +-----------+---------+
> | | |
> +--+---+ +--+--+ +-+--+
> |UserId| |Group| |Role|
> +------+ +-----+ +----+
>
>
> -Eric
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes (2 of 3) - JAAS Principals described
Posted by Peter Lynch <pe...@mindspring.com>.
If you are using cvs with cygwin, and vi is the editor that comes up, then
just type
:wq
-Peter
----- Original Message -----
From: "Gonzalo A. Diethelm" <go...@aditiva.com>
To: "Turbine Developers List" <tu...@jakarta.apache.org>
Sent: Friday, February 08, 2002 9:45 AM
Subject: RE: Security Changes (2 of 3) - JAAS Principals described
> > Everyone, I'm about to commit a couple of changes to my proposal;
>
> Aarrghhh! For the second time, I wrote a carefully worded
> comment to go along with the commit, and it was ignored by
> cvs! On Win2K, cvs brought up an editor screen where I typed
> the comment; I saved the file, exited the editor and chose
> '!', but the message was not used. The same thing has happened
> to me when choosing 'c'. What is the %$#"!$ proper way to
> do this?
>
>
> --
> Gonzalo A. Diethelm
> gonzalo.diethelm@aditiva.com
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (2 of 3) - JAAS Principals described
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> Everyone, I'm about to commit a couple of changes to my proposal;
Aarrghhh! For the second time, I wrote a carefully worded
comment to go along with the commit, and it was ignored by
cvs! On Win2K, cvs brought up an editor screen where I typed
the comment; I saved the file, exited the editor and chose
'!', but the message was not used. The same thing has happened
to me when choosing 'c'. What is the %$#"!$ proper way to
do this?
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Manager
Posted by Jason van Zyl <jv...@zenplex.com>.
On Fri, 2002-02-22 at 08:20, Viraf Bankwalla wrote:
> Hi,
>
> There were a number of discussions on this list
> regarding a Security Manager. Is the new security
> manager being implemented for the next release of
> Turbine (2.2.x), or for Release 3.0 ?
The full decoupling of security will happen in Turbine 3.x.
> What are the timelines for its implementation ?
There are none yet. We're still discussing the possibilities for the
default implementation.
> The proposed module appeared to be comprehensive, and
> I was wondering if this should be a commons component
> ?
It very well could be but, hopefully it will but we'll fully work it out
here first or at least have something working before proposing anything
as a commons component.
> There are several commons projects that have
> security requirements and I guess it would be nice to
> have a common security manager.
>
> Thanks.
>
> - viraf
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Manager
Posted by Eric Dobbs <er...@dobbse.net>.
On Friday, February 22, 2002, at 06:20 AM, Viraf Bankwalla wrote:
> There were a number of discussions on this list
> regarding a Security Manager. Is the new security
> manager being implemented for the next release of
> Turbine (2.2.x), or for Release 3.0 ?
The work is being done in Turbiine 3.
> What are the timelines for its implementation ?
> The proposed module appeared to be comprehensive, and
> I was wondering if this should be a commons component
> ? There are several commons projects that have
> security requirements and I guess it would be nice to
> have a common security manager.
You bring up a very good point here. The security system
we would like to create here might be more broadly useful.
Anyone have thoughts on putting our security code into
Stratum? (Am I right that stratum is eventually destined
for commons? And would therefore address some of Viraf's
suggestion?)
Here's a couple threads on security from avalon-dev:
http://marc.theaimsgroup.com/?l=avalon-dev&w=2&r=1&s=security+AAA&q=b
Looking through their mail archives it looks like the
Avalon folks have been having an almost identical
conversation to ours. It also looks like they are no
further along in the conversation than we are.
My intent has been to get a bit more implementation to focus
the conversation before approaching avalon, or commons, or
struts, or whoever for collaboration. I understand there are
some differences of opinion between turbine and avalon and
struts. Before opening that can of worms, I would like to
have some code to hopefully focus the conversation. Maybe I
have the wrong assumptions here. Opinions?
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Security Manager
Posted by Viraf Bankwalla <vi...@yahoo.com>.
Hi,
There were a number of discussions on this list
regarding a Security Manager. Is the new security
manager being implemented for the next release of
Turbine (2.2.x), or for Release 3.0 ?
What are the timelines for its implementation ?
The proposed module appeared to be comprehensive, and
I was wondering if this should be a commons component
? There are several commons projects that have
security requirements and I guess it would be nice to
have a common security manager.
Thanks.
- viraf
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes - blow by blow
Posted by Peter Lynch <pe...@mindspring.com>.
> > I think we need Scope where JAAS would have CodeSource.
> > It's not enough to ask "does the Subject have Permission?"
> > We need to be asking "does the Subject have Permission in this
> > Scope?"
Or
Does the subject have a capability to do X on a resource with permission X ?
Sounds an awful lot like you are checking the "capability"
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=capability
An operating system security or access control model where specific types of
access to a specific object are granted by giving a process this data
structure or token.
"capability" = specific object + permission
or
"types of access" == permission
"specific object" == resource
"giving a process this data structure" ==
Capability capability = new Capability(resource, permission );
checkPermission(subject, capability);
...but I guess the naming issue is at rest for now :-}
-Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes - blow by blow
Posted by Chris Holman <ch...@owl.co.uk>.
> -----Original Message-----
> From: Eric Dobbs [mailto:eric@dobbse.net]
> Sent: 14 February 2002 15:16
> To: Turbine Developers List
> Subject: Re: Security Changes - blow by blow
...
>
> I think we need Scope where JAAS would have CodeSource.
> It's not enough to ask "does the Subject have Permission?"
> We need to be asking "does the Subject have Permission in this
> Scope?"
>
> public boolean implies(Subject subject, Scope scope,
> Permission permission);
>
> And I think this also needs to be reflected when assigning the
> Permissions to Roles in the first place. This is why I don't
> think it's the right idea to model Scope as a Principal. I
> really think these are different animals. But I'm still
> willing to be persuaded otherwise.
Hmm... you certainly know how to throw a spanner in the works... :-)
Scope is necessary, as you so rightly point out, and my proposal
doesnt reflect this. :-( ...yet. ;-)
But, I have a problem getting my head round why CodeSource
and Scope should be treated in the same manner.
Lets say that a class called Project exists.
This class could be put into a collection, therefore a set of
many projects or scopes exist, but a single codeSource.
Have I understood the concept of Scope here?
What mechanism would be used by JAAS to provide permissions
based on which project/scope you were viewing/editing? The
CodeSource cannot be used to differentiate, as there is only
one.
Chris
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes - blow by blow
Posted by Eric Dobbs <er...@dobbse.net>.
Chris, I mostly like what you've posted, but I have a couple
issues. More comments inline...
-Eric
On Thursday, February 14, 2002, at 05:09 AM, Chris Holman wrote:
> Heres a(nother) summary of the Subject-Principal-Permission Model.
> Its mixture of JAAS and a couple of concepts to link it into Turbine.
>
> Does it makes any sense?
> Theres a small code snippet at the bottom to give an example of
> how this could be used in practice.
>
> Q: Is CodeSource authorisation required? Leaving it out does makes
> things a 'little' simpler.
In my proposal, I replaced CodeSource with Scope, because I think
CodeSource doesn't make a lot of sense in this context -- too tied
to standard Java Security for my taste.
> /**
> * The name parameter of the AuthenticationManager constructor
> * indicates the login configuration set i.e. a list of LoginModule
> * classes to be called during the call to login(). This is the
> * mechanism for "single login".
> * The login() method ensures that all LoginModules are called and
> * populates its subject with the relevant Principals and
> * Credentials.
> */
> public class AuthenticationManager{
> private Subject subject;
> public AuthenticationManager(String name);
> public void login();
> public void logout();
> public Subject getSubject();
> }
Thanks for adding this bit. I have been mostly ignoring the
authentication part of my discussions so I could focus on
authorization. But I think my skipping of that step has
confused matters a little.
> /**
> * A Subject is a container of authentication and authorisation
> * information about an entity . This entity could be a person,
> * a host or client. The infomation includes a set of principals
> * and credentials.
> * Credentials can hold information such as passwords,
> * certificates and keys, usually related to a login principal.
> */
> public final class Subject{
> private Set principals;
> private Set publicCredentials;
> private Set privateCredentials
> public Set getPrincipals();
> public Set getPublicCredentials();
> public Set getPrivateCredentials();
> }
>
> /**
> * This Interface is the key to mapping a Subjects capabilities to
> * permissions. Each class implemeting this interface represents
> * a type of capability a Subject has e.g. LoginTypeObtained,
> * Group, Project, Role, Scope etc. The model is flexible enough
> * to allow as many types as your aplication desires.
> * Each instance of these classes will have a name e.g.
> * For a Role class, use names such as administrator, manager,
> * developer, author etc.
> * For a loginKerberos class, use names such as joeb@the.realm
> * and joec@the.realm
> * For a loginX500 class, use names such as
> * "cn=joeb,o=organisation,l=Europe,dc=dot,dc=com"
> * The Policy class associates principals with permissions and
> * therefore determines what a Subject can do.
> */
> public interface Principal{
> private String name;
> public String getName()
> }
>
> /**
> * This interface extends Principal to allow it to contain
> * principals. A collection of principals can therefore be used
> * to determine whether a permission is granted. This is how the
> * Turbine permissions Tuple could be implemented.
> */
> public interface PrincipalSet extends Principal{
> public boolean addMember(Principal principal);
> public boolean removeMember(Principal principal);
> public boolean isMember(Principal principal);
> }
I know from your earlier post with an XML policy file
that you see the Scope being modeled as a type of
Principal. I don't understand how it'll work.
I think there are three fundamental pieces in the
Authorization: Principal, Scope, and Permission.
I think they are distinctly different pieces that should
not be modeled together. I'm willing to be persuaded
otherwise, but at the moment I don't understand why you
want to put Scope in as a kind of Principal.
Let me see if I can break the Turbine 2 security model
into pieces that fit into the JAAS way of thinking.
These four should be pretty obvious:
TURBINE_USER -> Principal
TURBINE_ROLE -> Principal
TURBINE_PERMISSION -> Permission
TURBINE_GROUP -> Scope
These are the tricky part:
TURBINE_ROLE_PERMISSION
TURBINE_USER_GROUP_ROLE
In Turbine 2, Permissions are granted to Roles without
providing the Scope of the Permission granted.
I can say "grant Managers EditPermission"
and "grant Managers CreatePermission"
and "grant Managers AdminPermission
This begs the question "to Edit, Create, or
Admin[istrate] *what* exactly?"
That question is answered by TURBINE_USER_GROUP_ROLE
At the time I assign the Manager Role to a User, I
specify "to *what*" in the GROUP column.
I see now that I was applying a reality distortion field
with this mapping a JAAS policy file and Turbine 2 security:
grant
codebase TURBINE_GROUP
Principal TURBINE_ROLE {
permission TURBINE_PERMISSION;
}
In Turbine 2, the Scope (TURBINE_GROUP) is not included
when Permissions are granted to Roles. Intead, the Scope
is included when Users assigned to Roles. The ingredients
are all there, but the order of operations are probably
important.
Have I identified the problem you are addressing?
> /**
> * This class must be extended to cater for type of storage used
> * for the policy information e.g. file, DB, LDAP etc. This
> * is a simplified example of the JAAS implementation. It could
> * be made to work as it stands, but lacks CodeSource checks. Is
> * relevant to Turbine?
> */
> public abstract class Policy{
> public boolean implies(Subject subject, Permission permission);
> }
I think we need Scope where JAAS would have CodeSource.
It's not enough to ask "does the Subject have Permission?"
We need to be asking "does the Subject have Permission in this
Scope?"
public boolean implies(Subject subject, Scope scope,
Permission permission);
And I think this also needs to be reflected when assigning the
Permissions to Roles in the first place. This is why I don't
think it's the right idea to model Scope as a Principal. I
really think these are different animals. But I'm still
willing to be persuaded otherwise.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes - blow by blow
Posted by Chris Holman <ch...@owl.co.uk>.
Heres a(nother) summary of the Subject-Principal-Permission Model.
Its mixture of JAAS and a couple of concepts to link it into Turbine.
Does it makes any sense?
Theres a small code snippet at the bottom to give an example of
how this could be used in practice.
Q: Is CodeSource authorisation required? Leaving it out does makes
things a 'little' simpler.
Chris
/**
* The name parameter of the AuthenticationManager constructor
* indicates the login configuration set i.e. a list of LoginModule
* classes to be called during the call to login(). This is the
* mechanism for "single login".
* The login() method ensures that all LoginModules are called and
* populates its subject with the relevant Principals and
* Credentials.
*/
public class AuthenticationManager{
private Subject subject;
public AuthenticationManager(String name);
public void login();
public void logout();
public Subject getSubject();
}
/**
* A Subject is a container of authentication and authorisation
* information about an entity . This entity could be a person,
* a host or client. The infomation includes a set of principals
* and credentials.
* Credentials can hold information such as passwords,
* certificates and keys, usually related to a login principal.
*/
public final class Subject{
private Set principals;
private Set publicCredentials;
private Set privateCredentials
public Set getPrincipals();
public Set getPublicCredentials();
public Set getPrivateCredentials();
}
/**
* This Interface is the key to mapping a Subjects capabilities to
* permissions. Each class implemeting this interface represents
* a type of capability a Subject has e.g. LoginTypeObtained,
* Group, Project, Role, Scope etc. The model is flexible enough
* to allow as many types as your aplication desires.
* Each instance of these classes will have a name e.g.
* For a Role class, use names such as administrator, manager,
* developer, author etc.
* For a loginKerberos class, use names such as joeb@the.realm
* and joec@the.realm
* For a loginX500 class, use names such as
* "cn=joeb,o=organisation,l=Europe,dc=dot,dc=com"
* The Policy class associates principals with permissions and
* therefore determines what a Subject can do.
*/
public interface Principal{
private String name;
public String getName()
}
/**
* This interface extends Principal to allow it to contain
* principals. A collection of principals can therefore be used
* to determine whether a permission is granted. This is how the
* Turbine permissions Tuple could be implemented.
*/
public interface PrincipalSet extends Principal{
public boolean addMember(Principal principal);
public boolean removeMember(Principal principal);
public boolean isMember(Principal principal);
}
/**
* This class must be extended to cater for type of storage used
* for the policy information e.g. file, DB, LDAP etc. This
* is a simplified example of the JAAS implementation. It could
* be made to work as it stands, but lacks CodeSource checks. Is
* relevant to Turbine?
*/
public abstract class Policy{
public boolean implies(Subject subject, Permission permission);
}
*******************************************************************
*******************************************************************
Heres and example of how they may be used:
AuthorisationManager am = new
AuthorisationManager("MyApplicationLoginConfig");
am.login();
Subject subject = am.getSubject();
XMLPolicy policy = new XMLPolicy("XMLPolicyFile.xml");
...
//if subject has permission to use the SSL connection to the
LDAPContactDirectory
if(policy.implies(subject, new SSLPermission("LDAPContactDirectory")){
//set up an SSL connection and access it
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes - blow by blow
Posted by Eric Dobbs <er...@dobbse.net>.
On Wednesday, February 13, 2002, at 04:56 PM, Gonzalo A. Diethelm wrote:
> A simple question for the "JAAS-like-model" proponents: does the
> concept of Principal have anything to do with the idea of single
> sign on? I mean:
>
> * A user U has id1/pwd1 in system 1, id2/pwd2 in system 2, etc.
> * We want to provide him with a single id/pwd through T3.
>
> Would each idX be a Principal (with an associated Password pwdX)
> for User U? Because if this is the case, I would concur that the
> User/Principal thing could be useful to us.
That's definitely one application of Principals in JAAS.
But as I've said in other posts in this thread, they are
used for more than just single sign on.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes - blow by blow
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
After being in six airports in five days, I finally have a minute!
A simple question for the "JAAS-like-model" proponents: does the
concept of Principal have anything to do with the idea of single
sign on? I mean:
* A user U has id1/pwd1 in system 1, id2/pwd2 in system 2, etc.
* We want to provide him with a single id/pwd through T3.
Would each idX be a Principal (with an associated Password pwdX)
for User U? Because if this is the case, I would concur that the
User/Principal thing could be useful to us.
If I'm totally off-base here, please disregard my question; I really
need to catch up with my sleep.
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes - blow by blow
Posted by Chris Holman <ch...@owl.co.uk>.
> -----Original Message-----
> From: Eric Dobbs [mailto:eric@dobbse.net]
> Sent: 12 February 2002 16:55
> To: Turbine Developers List
> Subject: Re: Security Changes - blow by blow
...
> <AuthorizationPolicy>
> <grant>
> <principal class="o.a.t.security.turbine.Role">
> Anonymous
> </principal>
> <scope name="PublishedArticles">
> <permission>ReadArticle</permission>
> </scope>
> </grant>
...
Hows about extending this to a more general form?
The PrincipalSet IF is an extension of the Principal IF. It can contain a
set of Principals. A Subject must have a principalSet of the correct class
and name, containing a matching set of principals before the Permissions
associated with the top level PrincipalSet or Principal can be granted.
<AuthorizationPolicy>
<grant>
<principalSet class="o.a.t.security.turbine.SpecialAccess>
principalSetName
<principal class="o.a.t.security.turbine.KerberosLogin">
loginName
</principal>
<principal class="o.a.t.security.turbine.Project">
projectName
</principal>
<principal class="o.a.t.security.turbine.Role">
RoleName
</principal>
<principal class="o.a.t.security.turbine.Scope">
ScopeName
</principal>
</principalSet>
</grant>
<grant>
<principal class="o.a.t.security.turbine.Project">
projectName
</principal>
</grant>
<grant>
<principal class="o.a.t.security.turbine.Group">
groupName
</principal>
</grant>
</AuthorizationPolicy>
Chris
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes - blow by blow
Posted by Eric Dobbs <er...@dobbse.net>.
On Tuesday, February 12, 2002, at 11:21 AM, Chris Holman wrote:
> [Eric Dobbs Wrote]
>> <AuthorizationPolicy>
>> <grant>
>> <principal class="o.a.t.security.turbine.Role">
>> Anonymous
>> </principal>
>> <scope name="PublishedArticles">
>> <permission>ReadArticle</permission>
>> </scope>
>> </grant>
> ...
>> </AuthorizationPolicy>
>
> It's looking like a reasonable proposition, but...
>
> An example that was quoted a while back in this thread was the way in
> which
> Scarab uses the concept of projects to provide permission macro sets
> within
> an application. How would this be accomplished with the proposed DTD?
> Would
> this require an extension to the DTD or have I missed something?
I believe that Scarab's Project is equivalent to the
<scope> I used above. See the "renaming 'Project'"
thread.
> I assume that each application will have its own <AuthorizationPolicy>
> entry? How would this effect the idea of single login for all
> applications.
> For that matter (a little off subject) how would single login be
> accomplished.
I haven't given much thought, yet, to single login.
I don't know if each app would have its own Policy
or not. As you can tell, it's gotten complex enough
just communicating the authorization details. I
expect to get to login stuff, but not right now.
Please suggest some options if you have some cycles
to offer to the discussion in this area.
>> The authentication code might look like this:
>>
>> SecurityManager sm = SecurityManager.getInstance();
>> try
>> {
>> TurbineSubject subject = sm.getSubject(userid,password);
>
> I know this wasnt intended to explain authorisation, but I flinch every
> time
> I see a userid and password pair passed as parameters between top level
> classes.
Sorry I didn't comment on that specifically. I was
trying to briefly get through the authentication
part so I could emphasize the authorization part.
> This is one aspect of JAAS I would like to see adopted in Turbine. I
> would
> like to use Certificate based login to Turbine. The current Turbine
> implementation makes this a little difficult due to the explicit use of
> user
> and password in the SecurityService interface.
When I get to thinking about authentication in more
detail, I expect to study JAAS implementation of
Pluggable Authentication Modules specifically to
open up options for certs or other forms of
authentication. If you have time to flesh these
ideas out, I'm all ears.
>> The tool would load that XML security policy into
>> memory when it is initialized.
>
> So that the Policy can be edited online, wouldnt it be better to have
> the
> Policy in a DB, or similar? Or add the flexibility to configure it. This
> would also be a nice concept to utilise from JAAS.
Another thing I wished I had said explicitly. The
purpose of my last email is to communicate the
concepts in more detail. XML seemed like a
convenient way to get the point across. I didn't
intend to present that as the implementation of
choice. Your suggestion of DB based policy
definition is exactly inline with what I have in
mind. The file-based policy was one of my early
complaints about JAAS default implementations for
Turbine. XML doesn't solve that problem. 8^)
> Sorry that there are so many questions and no solutions. Believe it or
> not,
> I like the general direction your taking this, just needs more
> polish. :-)
Polish is exactly why I'm putting so much time
into this discussion.
Thanks for the feedback.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes - blow by blow
Posted by Chris Holman <ch...@owl.co.uk>.
[Eric Dobbs Wrote]
> <AuthorizationPolicy>
> <grant>
> <principal class="o.a.t.security.turbine.Role">
> Anonymous
> </principal>
> <scope name="PublishedArticles">
> <permission>ReadArticle</permission>
> </scope>
> </grant>
...
> </AuthorizationPolicy>
It's looking like a reasonable proposition, but...
An example that was quoted a while back in this thread was the way in which
Scarab uses the concept of projects to provide permission macro sets within
an application. How would this be accomplished with the proposed DTD? Would
this require an extension to the DTD or have I missed something?
I assume that each application will have its own <AuthorizationPolicy>
entry? How would this effect the idea of single login for all applications.
For that matter (a little off subject) how would single login be
accomplished.
> The authentication code might look like this:
>
> SecurityManager sm = SecurityManager.getInstance();
> try
> {
> TurbineSubject subject = sm.getSubject(userid,password);
I know this wasnt intended to explain authorisation, but I flinch every time
I see a userid and password pair passed as parameters between top level
classes.
This is one aspect of JAAS I would like to see adopted in Turbine. I would
like to use Certificate based login to Turbine. The current Turbine
implementation makes this a little difficult due to the explicit use of user
and password in the SecurityService interface.
> The tool would load that XML security policy into
> memory when it is initialized.
So that the Policy can be edited online, wouldnt it be better to have the
Policy in a DB, or similar? Or add the flexibility to configure it. This
would also be a nice concept to utilise from JAAS.
Sorry that there are so many questions and no solutions. Believe it or not,
I like the general direction your taking this, just needs more polish. :-)
Chris
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes - blow by blow
Posted by Eric Dobbs <er...@dobbse.net>.
Hi All.
Here's the "Blow by blow" story.
First, we need an example application for the sake of
discussion. Let it be a simple web publishing
application. We have three sorts of users: anonymous
users who read the published articles, authors who
create the articles, and editors who edit articles and
schedule them for publication.
So there are three roles:
Anonymous, Author, and Editor
For this application we'll need some Permissions.
ReadArticle, CreateArticle, EditArticle,
PublishArticle.
And we'll need some Scopes.
AllArticles, PublishedArticles, OwnedArticles
And we need to define our Security Policy. In other
words, we need to map the scopes and roles and
permissions as appropriate for our application. For
now I'll use a simple xml format to express the
security policy.
<AuthorizationPolicy>
<grant>
<principal class="o.a.t.security.turbine.Role">
Anonymous
</principal>
<scope name="PublishedArticles">
<permission>ReadArticle</permission>
</scope>
</grant>
<grant>
<principal class="o.a.t.security.turbine.Role">
Author
</role>
<scope name="OwnedArticles">
<permission>ReadArticle</permission>
<permission>CreateArticle</permission>
<permission>EditArticle</permission>
</scope>
</grant>
<grant>
<principal class="o.a.t.security.turbine.Role">
Editor
</principal>
<scope name="AllArticles">
<permission>ReadArticle</permission>
<permission>EditArticle</permission>
<permission>PublishArticle</permission>
</scope>
</grant>
</AuthorizationPolicy>
I think the following DTD is right, but I'm not
entirely sure.
<!ELEMENT AuthorizationPolicy (grant+)>
<!ELEMENT grant (principal+, scope+)>
<!ELEMENT principal (#PCDATA)>
<!ATTLIST principal class CDATA #REQUIRED>
<!ELEMENT scope (permission+)>
<!ATTLIST scope name CDATA #REQUIRED>
<!ELEMENT permission (#PCDATA)>
With that in mind, here's how I think the system would
work.
When a user visits the application for the first time,
a Subject is attached to their session, and the
AnonymousPrincipal is attached to the Subject. They
are assumed to be Anonymous unless they login. As an
anonymous user they are presented with a list of
published articles.
Suppose that the user is an Author who now chooses to
login. They are challenged to provide a userid and
password to verify their identity. When those
credentials are verified, the authentication code is
responsible for checking the records about the user and
attaching all appropriate principals to the Subject in
the session. In the case of an author two Principals
are added: a TurbineUserPrincipal which holds their
UserId, and a Role for "Author".
The authentication code might look like this:
SecurityManager sm = SecurityManager.getInstance();
try
{
TurbineSubject subject = sm.getSubject(userid,password);
// put the subject into the session object
// NOTE:
// getSubject() is responsible for populating
// the Subject with its Principals. In the
// case of an "author" that code might look
// like this:
// subject.getPrincipals().
// add(new TurbineUserPrincipal(userid));
// subject.getPrincipals().
// add(new Role("Author"));
// subject.getPrincipals().
// add(new Role("Anonymous"));
// (no reason not to grant the author the same
// rights as anonymous users)
}
catch (AuthenticationException e)
{
// notify user of authentication failure
}
Once the user is authenticated the application should
now present them with additional options as appropriate
for their permissions.
The template for the articlelist.vm might look like the
following. Assume for the sake of this conversation
that there's a security manager tool ($sm) and the
Subject ($subject) in the velocity context.
#if ($sm.isPermitted($subject,"OwnedArticles","CreateArticle"))
<a href="$link...">Create Article</a><br>
#end
#if ($sm.isPermitted($subject,"OwnedArticles","EditArticle"))
#foreach ($article in $articles.getArticlesByOwner($subject))
#renderHyperlinkToEditArticle($article)
#end
The tool would load that XML security policy into
memory when it is initialized. And the isPermitted()
method is responsible for interrogating that structure
to determine if any of the $subject's principals have
been granted the "EditArticle" permission in the
"OwnedArticles" scope.
I trust you'll ask for details where I have not been
clear or complete enough.
-Eric
ps. I should just add this: although in my example I
have used Roles to group permissions, it should be
clear from earlier postings that this could just as
easily be Groups (like orgainzational units, or
geographic groups, or whathaveyou). Similarly, I could
grant a user special permissions by attaching those
permissions to their userid principal.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (2 of 3) - JAAS Principals described
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> Thick-headed? I think not. 8^) Seems like a very sneaky
> way to see if I really know what I'm talking about, and if
> I can explain it clearly. 8^)
Got me there... ;-)
> It's also going to take me a while to put a blow by blow
> example together, but I'll give it a shot later today or
> maybe over the weekend.
Great!
Everyone, I'm about to commit a couple of changes to my proposal;
basically, the introduction of a Scope concept (preliminary name,
can be changed later) and the use of newInstance() to avoid tying
TurbineSecurityManager to specific classes (they are still
hard-coded, but now as Strings, not imports).
This is the last I will be able to contribute to this thread
in terms of coding until the 18th. I'll try to keep on top of
the mail messages. I do have high hopes that we will be able
to home into a simple and very configurable default implementation
of a security system, so everyone please keep contributing to
the discussion!
One more thing: anyone volunteers for writing an implementation
of T2's security system using my proposal? (yeah, right).
> -Eric
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes (2 of 3) - JAAS Principals described
Posted by Eric Dobbs <er...@dobbse.net>.
On Friday, February 8, 2002, at 05:19 AM, Gonzalo A. Diethelm wrote:
> I'm very thick-headed... Can you provide a blow by blow
> example of these concepts? Something like "User U1 has
> Principals P1 and P2, which in turn...", etc., but
> hopefully with names for each entity that are from a
> real-life requirement?
Thick-headed? I think not. 8^) Seems like a very sneaky
way to see if I really know what I'm talking about, and if
I can explain it clearly. 8^) It'll be good for the
documentation I promised to contribute too.
It's also going to take me a while to put a blow by blow
example together, but I'll give it a shot later today or
maybe over the weekend.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (2 of 3) - JAAS Principals described
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> First, and most important for Turbine, Principals are
> where Roles and Groups would be implemented.
>
> Second, and also important for Turbine, Permissions are
> connected to Principals, not directly to subjects.
>
> Third, the Subject would have many Principals, one of
> which serves as the userid.
>
> Fourth, Principals come into play in Pluggable
> Authentication Modules (PAM). This allows an
> administrator of an application to choose their own
> authentication technologies and policies. (LDAP, DB,
> ActiveDirectory, Kerberos,...)
>
> Fifth, Principals are used to enable a Subject to login
> once and be granted access to many applications.
I'm very thick-headed... Can you provide a blow by blow
example of these concepts? Something like "User U1 has
Principals P1 and P2, which in turn...", etc., but
hopefully with names for each entity that are from a
real-life requirement?
> +-------+ 1 N +---------+ 1 N +----------+
> |Subject+-------+Principal+----------+Permission|
> +-------+ +----+----+ +----------+
> |
> +-----------+---------+
> | | |
> +--+---+ +--+--+ +-+--+
> |UserId| |Group| |Role|
> +------+ +-----+ +----+
Shouldn't Role be changed into Project, as per your other
messages?
> -Eric
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (2 of 3) - JAAS Principals described
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> JAAS seems to provide the flexibility I require:
>
> * Single login.
> * Authentication to an LDAP Certificate store over SSL (LDAPS).
> * LDAPS, or possibly Database, based Policy/Permissions store.
>
> The current Turbine SecurityService seems to be purely
> user/password orientated. Is Certificate based login being
> considered for the next framework?
In a purely abstract way, yes. We won't really know for sure
until we have an implementation that shows everything fits
together. Want to volunteer?
> Chris
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (2 of 3) - JAAS Principals described
Posted by Chris Holman <ch...@owl.co.uk>.
Eric,
Thanks for the summary. It clarified a few grey areas.
[ Eric Dobbs ]
> The harder I look at the JAAS terminology and model,
> the more it makes sense to me. That's why I keep
> pushing it. I think it is fairly well thought out and
> worth trying to understand.
I have spent the last few days researching the JAAS and
have to confer with Eric. JAAS is an extremely well
thought-out and flexible authentication and authorisation
framework! Why try and re-invent the wheel?
JAAS seems to provide the flexibility I require:
* Single login.
* Authentication to an LDAP Certificate store over SSL (LDAPS).
* LDAPS, or possibly Database, based Policy/Permissions store.
The current Turbine SecurityService seems to be purely
user/password orientated. Is Certificate based login being
considered for the next framework?
Chris
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>