Re: [securityfilter-devel] Securityfilter + JBoss

[Sverker A. <sv...@ab...>]

Hi,

> -----Original Message-----
> From: Christopher Schultz [mailto:ch...@ch...]
> Sent: den 29 april 2010 11:53
> To: Sverker Abrahamsson
> Subject: Re: [securityfilter-devel] Securityfilter + JBoss
> 
> Sverker,
> 
> On 4/29/2010 4:16 PM, Sverker Abrahamsson wrote:
> >> -----Original Message-----
> >> From: Christopher Schultz
> >> Subject: Re: [securityfilter-devel] Securityfilter + JBoss
> >>
> >> If you are correctly using SecurityRequestWrapper, then you should
> be
> >> getting the principal created by your realm. Are you saying that,
> >> when using a custom realm, your Principal is being overwritten by
> the
> >> JBossGenericPrincipal?
> >
> > No, it's not overwritten. My Principal is contained in the
> > userPrincipal property of the GenericPrincipal instance returned from
> > authentication.
> 
> If you are getting a GenericPrincipal from JBoss, is it possible to
> unwrap it in your custom authenticator, or does that break other
> things?

It might be possible, the only place where it would make a difference is when calling realm.isUserInRole, but the JBossRealm doesn't use the supplied principal there anyway.

> > For the JBossRealm it's not necessary to use SecurityRequestWrapper
> as
> > the necessary fields are set by security framework in the original
> > request.
> 
> Can you be more specific? SecurityFilter uses SecurityRequestWrapper to
> manage a lot of things for itself. If JBoss can handle the
> authentication and authorization without using SecurityRequestWrapper,
> I think I'm misunderstanding what part of sf you're actually using.

You need to use the SecurityRequestWrapper to present your own Principal instance instead of the one from original request. The rest wouldn't be difficult to refactor out.
 
> > However, that wouldn't work with other securityfilter realms as they
> > depends on that securityfilter patch in their principal. The best way
> > might be that the realm has a method like this:
> >
> > public HttpServletRequest createRequestWrapper(HttpServletRequest
> > request)
> >
> > Then the realm is responsible for wrapping the request and can return
> > an implementation which is suitable. However, that would be a bigger
> > change of the code.
> 
> sf is currently undergoing essentially a complete rewrite, which
> includes the ability to meaningfully extend and override the
> capabilities of most components. I hadn't considered allowing the
> authenticator (I prefer that name over "realm") to modify the request
> itself, but there is a method in the new filter code for that. Here's
> the current (pre-alpha) implementation:(apologies for the wrapping).

As I see it authenticator implements the org.securityfilter.authicator.Authenticator interface and do the frontend part, such as fetching data from form fields etc. Realms implements the org.securityfilter.realm.SecurityRealmInterface
 
>     protected SecurityRequestWrapper wrapRequest(HttpServletRequest
> request)
>     {
>         // TODO: Use a factory to allow users to specify the class to
> use
>         // for wrapping? Or, make this a pipelined operation.
>         return new SecurityRequestWrapper(request,
> 
> getSecurityConstraint(request),
>                                           _securityStorageManager);
>     }
> 
> The core class in which this method lives can be extended to wrap the
> request in (almost) any way, and it's a much easier customization than
> changing the way that all realms are handled by sf.

It could be a method on the FlexibleRealmInterface, so that the standard realms doesn't have to change.
 
> -chris

/Sverker