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