LazyInitializationException, JpaIdentityStore

[dsailer.d.sailer.comcast.net]

I'm trying to setup up to use JpaIdentityStore and I'm getting a LazyInitializationException when org.jboss.seam.security.management.IdentityManager tries to retrieve the roles of the user during login. I'm using seam managed persistence context: components.xml:

   <persistence:managed-persistence-context name="entityManager"
                                     auto-create="true"
                      persistence-unit-jndi-name="java:/auto_classifieds_adminEntityManagerFactory"/>

                     
the login.page.xml:

   <navigation from-action="#{identity.login}">
      <rule if="#{identity.loggedIn}">
         <redirect view-id="/home.xhtml"/>
      </rule>
   </navigation>

the User:  

   
@Restrict //restrict all access by default (so we require an Authorization)
@Entity
@Table(name = "user")
@EntityListeners( { PrePersistListenerImpl.class })
public class User implements java.io.Serializable, LastUpdateAware {

<snip>
  private List<UserRole> roles;
  
  @UserRoles
  @ManyToMany(targetEntity = UserRole.class)
  @JoinTable(name = "UserToRole", 
      joinColumns = @JoinColumn(name = "userId"), 
      inverseJoinColumns = @JoinColumn(name = "roleId"))
  public List<UserRole> getRoles() {
    return roles;
  }

 
 
This is all set up very much like the seamspace example so I can't see what is causing the problem.

[dsailer.d.sailer.comcast.net]

Ok, this seems a bit odd to me but I found that when I have @Restrict on my UserRole class, I get the LazyInitializationException. Why would hibernate ORM be affected by @Restrict? So I took that off (for now anyway since my permission checks aren't working yet anyway)

So now I'm trying to get the target matches to work on my permission checks. I think there may be some issues with the seam code in IdentifierPolicy.getIdentifier(Object) but I'd like to hear others opinions. For one thing, it allows you to override the IdentifierStrategy with a @Identifier annotation (I did this to fix another issue described below) but then it overlays that in the hashmap with it's EntityIdentifierStrategy.

The reason I was trying to override the IdentifierStrategy is because of ClassIdentifierStrategy's implementation of canIdentify:

   public boolean canIdentify(Class targetClass)
   {
      return Class.class.equals(targetClass);
   }

when would someone's targetClass ever be Class.class? The result seems to be that the default strategy is record based (EntityIdentifierStrategy) which is probably not what most people want. Couldn't ClassIdentifierStrategy canIdentify just be:

  public boolean canIdentify(Class targetClass)
  {
     return targetClass instanceof Class;
  }

What am I missing here?

[dsailer.d.sailer.comcast.net]

I think what I'm missing here, and what the docs aren't clear on, is when is ClassIdentifierStrategy used vs EntityIdentifierStrategy? What is the strategy/design to handle a basic use case like this: you have products and customers. An admin can access any products so it is class level (should be able to do this without rows in JpaPermissionStore). An admin can also access any customers. However a customer can only access their own customer data. I'd like to handle the class level permissions in JpaPermissionStore and the record level permissions in code (I'd rather use java than drools since I think my use case is pretty simple). My starting point was to put @Restrict on my entities and configure a JpaPermissionStore for class level permissions, then figure out where to put the java hooks to handle row level/customer permissions.

[dsailer.d.sailer.comcast.net]

I suspect most others are not using @Restrict (w/ no parameters) on their entities. While this provides detailed control over security, I'm finding it a bit difficult in practice. Another issue I hit was that login always fails the first time because the principal does not yet have access to the User object. I think it's a chicken-egg timing issue. You need to be logged in to get rolls but need access to an entity to check rolls to log in. Anyway, I think maybe I'll explore using security at the action bean level.