Ron,
First, thanks again for being so helpful.
> > - Is there a way to package a SAM in an ear ? how ?
>
> yes, but this is a little opposite of the 196 philosophy; which sought to
> preserve decoupling between the app and the underling container security
> system (being extended by the Sam). include it as a pojo in your ear. it
> will need to be on the application classpath. you can bind it to your app
> via a message-security-binding in sun-ejb-jar.xml (assuming you are ok with
> application coupling), or you can use a custom authconfigprovider to bind
> the sam without changing your app.
Wonderful :)
I understand the philosophy of decoupling apps and containers in 196 but I
would like the deployment team to just drop an ear into GF so this solution
is ok for me.
> if you can get the httpServletRequest, you can find the ssl certificate
> stored in an attribute of the request (see the Servlet spec for details)
>
> ServletRequest.getAttribute("javax.servlet.request.X509Certificate");
I didn't realize that the MessageInfo provided access to the servlet request.
Thanks !
> I am not sure if the httpServletRequest is available to an ejb web service
> endpoint (but I think it is). Hopefully one of our jaxws security experts
> can help with this.
It is, I'm already using the httpServletRequest from ejb webservices, I'm
getting it from the MessageContext available in WebServiceContext.
> The SAM is invoked before the webservice invocation and after it, if there
> is a transaction that whose scope encapuslates the web service incocation,
> then the SAM will be invoked within the transaction.
So, my SAM implementation can perform database operations that will
participate in the current UserTransaction. Nice to read :)
That leads me to another question : is it possible to inject @EJBs in a SAM.
If not I'll do good'ol jndi lookups.
Best regards
Paul