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