[Security & JAAS/JBoss] - Re: need advice
by info＠connext.co.za
Good Day,
The SecurityAssociation is used by the ClientLoginModule to stuff the Principal and Credentials into the calling threads context so that this can authenticated by the security inteceptors before a EJB call is processed.
Is a SecurityException being thrown because the ClientLoginModule makes use of PrivilegedAction implemented in the internal class SecurityAssociationActions.
Try changing the java security policy for the code to all or use a PrivilegedAction.
| /**
| * Set the current principal information. If a security manager is present,
| * then this method calls the security manager's <code>checkPermission</code>
| * method with a <code> RuntimePermission("org.jboss.security.SecurityAssociation.setPrincipalInfo")
| * </code> permission to ensure it's ok to access principal information. If
| * not, a <code>SecurityException</code> will be thrown.
| * @param principal - the current principal identity.
| */
| public static void setPrincipal(Principal principal)
| {
| SecurityManager sm = System.getSecurityManager();
| if (sm != null)
| sm.checkPermission(setPrincipalInfoPermission);
|
| if (trace)
| log.trace("setPrincipal, p=" + principal + ", server=" + server);
| if (server)
| {
| threadPrincipal.set(principal);
| }
| else
| SecurityAssociation.principal = principal;
| // Integrate with the new SubjectContext
| SubjectContext sc = threadSubjectStacks.peek();
| if( sc == null )
| {
| // There is no active security context
| sc = new SubjectContext();
| threadSubjectStacks.push(sc);
| }
| else if( (sc.getFlags() & SubjectContext.PRINCIPAL_WAS_SET) != 0 )
| {
| // The current security context has its principal set
| sc = new SubjectContext();
| threadSubjectStacks.push(sc);
| }
| sc.setPrincipal(principal);
| if (trace)
| log.trace("setPrincipal, sc="+sc);
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971393#3971393
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971393
19 years, 7 months
[JBoss Seam] - Re: multi portlet setup
by mzeijen
I discovered that it is possible to get an entitityManager or entityManagerFactory over the JNDI. This way it is possible to get entities from a seperate ejb package (not embeded in the EAR file of the Seam application (or in my case the multiple portlets)).
In my class where I want to get the enitityManager I have multiple options to retrieve one:
1. Use a JNDI lookup to get the entitityManager or the factory
2. Use the @Resource annotation
3. Use the Seam-managed persistence context (but that only works for a conversation long entityManager)
I can't use the normal @PersistenceContext annotation because I get exceptions when I redeploy the ejb package that contains the entities.
My problem is that I don't know how to get an Extented EntityManager without using the @PersistenceContext annotiation.
You, Gavin, told me in a different topic that it isn't possible to have entities in a seperate ejb. But so far I succeeded pretty well. But because I also know that you are probably right, I would like to know for what implications I am heading for (next to the fact that I can't retrieve an Extended manager). Thx.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971391#3971391
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971391
19 years, 7 months
[JBoss Seam] - Glaring Security Hole?
by bfagan
Please correct me if I'm mistaken, but my impression from the Seam Reference document is that if you enable Seam Remoting then any Entity bean that you've given a Seam @Name has it's data model exposed.
Let's say you have a large corporation and a developer uses a wonderful IDE wizard to turn their database model into a package of easy to use Seam-enabled entities. Next the developer enables Seam Remoting to use an @WebRemote enabled session bean.
Any competitor to said large corporation can search javascript segments for Seam.Component.newInstance() methods, call out to the Seam Remoting URL garner information about the entities and reverse engineer a data model.
It is clear that session beans require @WebRemote annotation. Why are entity beans automatically exposed without such an annotation?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971389#3971389
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971389
19 years, 7 months