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 [EMAIL PROTECTED]
> * and [EMAIL PROTECTED]
> * 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
