I've been looking over Shane's article on security, and I'm really impressed with what the redesigned security API has to offer. Looking at seamspace, though, I was wondering why the MemberAccount and Member classes are separate. It would seem that Member just stores
details of the MemberAccount, but it also duplicates the MemberAccount's username as its memberName (correct me if I'm wrong). So, is there anything technically preventing the classes from being combined into one? To me, it would be a lot simpler if there was one class for everything having to do with a user.
In other words, instead of MemberAccount having a @OneToOne member property, there would be no MemberAccount at all. Instead, Member would have the @UserPrinciple, @UserPassword, @UserEnabled, and @UserRoles properties as well as email, gender, memberSince, etc. This bean could then be outjected upon creation or login from something like @Observer(JpaIdentityStore.EVENT_USER_AUTHENTICATED)
public void onLogin(Member member)
I know this is bleeding-edge technology, but any thoughts?
The decision to have two classes is simply intended to separate potentially sensitive information (the member's username and password hash) from their more public details. While it's not really an issue in SeamSpace, it may be more of an issue in an application that supports remoting or web services.