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/12 17:55:28 UTC
Re: Security Changes - blow by blow
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 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>