> Hi all,
>
> I need to build an enterprise app with custom autz.
> Auth is achieved via ssl client certificate.
>
> This app is made of ejb webservices and I would like
> to use the java security annotations, like
> @RolesAllowed, on their operations.
>
> I currently use the CertificateRealm mapped to a
> group name that I use in the META-INF/sun-ejb-jar.xml
> file with
> <transport-guarantee>CONFIDENTIAL</transport-guarantee
> >.
>
> With this, my webservices methods are only accessible
> to ssl certificate authenticated clients.
>
> Apart from this, I have custom business logic that
> retrieve roles based on the certificate info (subjet
> DN, cert serial and issuer DN). This custom logic is
> using JPA, LDAP and external WebServices to retrieve
> the roles.
>
> Now I would like to bind this custom logic into GF so
> I can use container based autz. Is it possible ?
> Googling a lot, I was only able to find simple use
> cases like jdbcRealm or ldapRealm. And all of this
> needed to be installed/configured in the GF domain.
> Ideally I would like to package what is needed inside
> the app EAR so deployment remain easy.
>
> Maybe I'm asking GF too much, but any solution or
> advice will be greatly appreciated. If I'm stuck to
> building custom autz handling, do you have any advice
> for doing it the EE way ?
>
>
> Best regards
>
> Paul
I think your goals are as follows:
1. use ssl mutual auth to authenticate web services
2. inject some code to effect role mapping based on certificate identity
3. rely on the ejb container's pre-dispatch authorization checks and have the effects of 2 be applied in the access check
4. package the code that does 2, such that it is deployed with the app.
if you want to achieve 3, then 2, will need to occur before you dispatch to your component.
I (think) one way to do 2, assuming you are ok with using glassfish proprietrary and internal apis, might be to write an ejb pre-invoke interceptor, that gets the currrent security context, and that uses the transport layer id, and uses it to add corresponding group principals to the subject in the security context.This will only work if the
interceptor will be invoked before the access check.
another way to do 2, would be to configure a soap layer jsr 196 server auth module, and have your app configure it, and register it for use by the container on its (i.e., your apps behalf). your auth module would achieve the same effect as described above, but it would do so, by using the standard callbacks defined by 196.
a third alternative would be to create a jacc policy provider that wraps the glassfish policy provider, and that adds principals during the policy decision, depending on the target of the access check.
Ron
[Message sent by forum member 'monzillo' (monzillo)]
http://forums.java.net/jive/thread.jspa?messageID=272790