Hi,
I have a design question and am looking for some other peoples
thoughts on best practices.
In one applicaiton (deployed as an .ear) I have a number of projects:
* customer-webapp is a war and is jax-rs (jersey)
* customer-object-model is a bunch of jaxb-annotated beans
* business-logic contains both logic + persistence (will be split out later)
Not part of the ear:
* glassfish-auth: a custom AppservRealm and
AppservPasswordLoginModule for glassfish
My authentication layer does the usual thing, but it attaches my own
custom Principal to the Subject. This Principal has extra data
associated with it (beyond just Principal and Groups). This
information includes a pointer to a specific database associated with
that login, as well as some other information about the customer.
In the webapp I get the Principal from SecurityContext (a jax-rs
class), then if possible safely upcast it to my own Principal.
The question is: what's the best way to get this to the EJB layer?
Things I have tried:
1. Create a provider method, in the webapp, to retrieve the
CustomerPrincipal from the SecurityContext, then in the bean:
@RequestScoped
public class BusinessBean {
@Inject CustomerPrincipal pal;
...
}
The terrible thing about this design is that EJB layer can no longer
exist without the webapp. Long term I want to be able to remote the
EJBs so that other applications can make use of the common business
logic and persistence.
2. Try to get the Principal injected directly in, but I can't figure
out how. SessionContext doesn't seem to apply to RequestScoped beans;
RequestContext can't be injected. The only idea I have left is:
Subject subject = (Subject)
PolicyContext.getContext("javax.security.auth.Subject.container")
but this seems hackish (?)
3. The other idea I had was that I could simply require all users to
pass the extra information into the business logic beans as properties
(i.e. setCustomer(x), setYourDatabase(y). This doesn't seem to fit
the pattern, though, requiring the callers to do stuff beyond what I
would normally expect them to have to know about. The caller just
wants to say "Hi, I'm Fred, and I want you to store this thing." I
would expect the business logic side to be responsible for figuring
out where to store it, in the most efficient manner possible.
Does anybody have any experience with patterns/best practices that
relate to this?
--Chris