[Rats, replying again thanks to the webmail line eater:-(]
At 00:42 17/07/01 -0400, SG wrote:
>Hi Wayne,
>
>It's Robert again. Sorry if I'm pulling you away from your project.
>
>As I stated before, I'm trying to use JAAS, however there is a major problem
>with JAAS as I see it. The policy file, which determines permission granting
>based on a Principal, is not very convenient when working with XML
>descriptors. In EJB, a bean designer/deployer has to worry about an XML
>descriptor to describe security access to their bean. I LIKE this! I much
>prefer it to the way that java makes its policy files. So my question is
>along the lines of:
>
>1. Is there any way to use an XML file instead of a descriptor for policy?
Yes, you can use anything you want to implement the policy. In J2SE 1.3
you just extend javax.security.auth.Policy, and then call Policy.setPolicy
to install your policy object. In J2SE 1.4 it is slightly different as
the CodeSource-based Policy and Subject-based Policy classes have been
combined.
>Is there a way to programatically set the policy permissions? If there is,
>then I could do it upon EJB Server startup. All I'd have to do is loop
>through the descriptors and add the permissions like so:
> loop through bean A descriptor
> if find Principal (role-name) under method, then
> security.policy.add Security.Grant(new
>myPrincipal(NODE(role-name)), "bean.method", permission type);
> end loop
>
>or something like that. So, do you know how to programatically add
>permission (grants) sets to the security policy? I think that would solve
>the problem of XML descriptor to policy mapping.
We will be doing this, more-or-less in Lutris EAS4, although we
register the permission grants at deployment time rather than at
startup of the EJB container.
We have proposed some permission classes, although I don't think they're
implemented yet (EJBMethodPermission and EJBNamedRolePermission I think).
Also note that JSR-115 is working on standardising the permission checks
that should happen in J2EE containers.
>2. If I can use the above, how does this affect my AccessControlContext? I
>know that this is instantiated with a ProtectionDomain[]. And a
>ProtectionDomain is instantiated with a CodeSource (which is a policy file).
>So can I instantiate this with a null one (or an empty file) and then add
>the permissions later?
In J2SE 1.3, changing the Subject after a ProtectionDomain is instantiated
does not affect it. In J2SE 1.3, ProtectionDomains include Principals,
but I must admit I'm not clear whether they can be changed for classes
that are already in your execution context.
>Other than above, of course, the biggest issues left are all related to
>authorization. Authentication I think integrates fairly well. The problem
>comes up with the AccessController, and Subject.doAs() and the "action"
>needing to have a run() method. I think what I'll have to do is make a
>"JonasActionClass" which you have to instantiate with (transactionAttribute,
>methodSignature). Then in the run() method, this class will do what
>preinvoke(), invoke() currently do. (their signatures are also of the
>(tranAttr, methodSig) manner).
>
>What do you think? Does this seem to fit with your understanding of the
>Jonas structure?
I'll have to pass on that, I don't understand the JOnAS structure well enough!
>looking forward to your input, (and anyone else who can help shed some light
>on this for me)
>Robert Paris
Cheers,
- Craig.
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
