The example code relies on the JBoss specific SecurityProxyInterceptor to establish the JAAS context and the org.jboss.test.security.proxy.ProjRepositorySecurityProxy2 performs the permission checks using the AccessController and other logic.
> The problem that I had was this: AccessController relies on your subject > being stored in a "thread" variable (i.e. static variable mapped to the > thread.) In non-EJB code, you can use "Subject.doAs" or > "Subject.doAsPrivileged" to set your subject after logging in. In EJB, > however, this is not safe because the spec does not guarantee thread or JVM > consistency over cross-EJB calls. (Correct?) Correct in that the bean author has no control over how its calls are dispatched and whether the Subject associated with the caller thread is propagated. > The best solution I could come up with is sort of a hack, but it should > work. You can use "getCallerPrincipal" to retrieve the principal from the > EJB context... Make a new subject to contain that principal, you don't need > to add credentials because AccessController doesn't care about those. > Execute "Subject.doAsPrivileged" with your new principal, and an anonymous > inner PrivilegedAction class, and perform your > "AccessController.checkPermission" in there. (I've written a small test, > and it works, but it ain't pretty.) > > Scott, is this pretty much what you had in mind, or did you have a better > solution? If your going to try to do something in an app server independent manner that is what you need to do. I simply use the JBoss security proxy interceptor as portable custom security is something of an oxymoron due to the lack of support in the J2EE specs. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Michael Jara" <[EMAIL PROTECTED]> To: "JBOSS_USER" <[EMAIL PROTECTED]> Sent: Wednesday, October 10, 2001 11:09 AM Subject: Re: [JBoss-user] Fine grained security & JBOSS I was working on a solution similar to this, using JAAS authorization with EJBs. After looking at your (Scott's) code, I didn't see any checks done with the AccessController. The problem that I had was this: AccessController relies on your subject being stored in a "thread" variable (i.e. static variable mapped to the thread.) In non-EJB code, you can use "Subject.doAs" or "Subject.doAsPrivileged" to set your subject after logging in. In EJB, however, this is not safe because the spec does not guarantee thread or JVM consistency over cross-EJB calls. (Correct?) The best solution I could come up with is sort of a hack, but it should work. You can use "getCallerPrincipal" to retrieve the principal from the EJB context... Make a new subject to contain that principal, you don't need to add credentials because AccessController doesn't care about those. Execute "Subject.doAsPrivileged" with your new principal, and an anonymous inner PrivilegedAction class, and perform your "AccessController.checkPermission" in there. (I've written a small test, and it works, but it ain't pretty.) Scott, is this pretty much what you had in mind, or did you have a better solution? Mike ----- Original Message ----- From: "Scott M Stark" <[EMAIL PROTECTED]> To: "JBOSS_USER" <[EMAIL PROTECTED]> Sent: Wednesday, October 10, 2001 11:44 AM Subject: Re: [JBoss-user] Fine grained security & JBOSS > > I'm still unsure how one would implement security in respect of entity > > "ownership". Assume I have an entity, e.g. an Appointment in a Schedule > > and want to grant read and write permissions to certain roles or users. > > How would I implement this logic. One solution that comes to my mind is > > à la "if (entity.canRead(getCallerPrincipal())" and manage the Users / > > Principals with a custom jboss security adapter which works on top of > > the application's user model. > > Is there any standard / existing jboss security adapter which works on > > top of a simple ejb user + role model? > > > > -billy. > > The most natural solution in my mind is to use Java2 style permission. > > Permission p = new DocumentPermission(docName, "read"); > AccessController.checkPermission(p); > > When coupled with JAAS subject based permissions this provides an elegant > solution. There is an example of using this type of custom permissions for a > JNDI model that checks for permissions like your are talking about. I have > not > had time to document this so you'll have to just try to wade through the > code > which is made up of these classes: > > org.jboss.test.security.ejb.project.ProjRepositoryBean > org.jboss.test.security.proxy.ProjRepositorySecurityProxy2 > org.jboss.test.security.test.NamespacePermission > _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
