securityfilter-devel — Security Filter Developers list

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

Re: [securityfilter-devel] Securityfilter + JBoss

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

I solved a problem I saw, I contributed the solution back to the project. It's your choice if you want to use it as it is, modify it, only parts of it or not at all.

I know of at least 5 different project which all use their own patched securityfilter to solve this same problem but none works very well. I found a perfectly working solution, I've published it so that if anybody want to use it then the patch can be downloaded from http://www.abrahamsson.com/securityfilter.patch

I also found a way to solve the original problem, without using security filter at all. I'll publish it at a suitable place when I have time for it.

See the rest of the comments below
/Sverker

> -----Original Message-----
> From: Christopher Schultz [mailto:ch...@ch...]
> Sent: den 27 april 2010 5:07
> To: Sverker Abrahamsson
> Cc: sec...@li...
> Subject: Re: [securityfilter-devel] Securityfilter + JBoss
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Sverker,
> 
> No need to reply to both me and the list: I am subscribed to it.
> 
> On 4/26/2010 6:53 PM, Sverker Abrahamsson wrote:
> > Correct, Request is the internal Catalina class for which they
> > provide a wrapper. The reason for this is that the Principal returned
> > by JBoss is a JBossGenericPrincipal so that is what is set as
> > principal in your wrapper, I believe it's the same for pure Tomcat as
> > well. To get the User Principal from that you need to call
> > principal.getUserPrincipal(). That is why I check if the principal is
> > an instance of GenericPrincipal and if so return the actual User
> > Principal.
> >
> > The reference to Tomcat Request here was just to show that internally
> Tomcat do the same
> 
> My question was: why should we change anything at all? What is the
> problem with the current implementation?

It doesn't work well with JBoss, that's problem enough for me.
 
> >>> If the Pincipal is an instance of
> >>> GenericPrincipal then it’s necessary to call getUserPrincipal on
> the
> >>> Principal to get the UserPrincipal. Also added a getPrincipal
> method
> >>> which is used internally where the full Principall is needed.
> >>
> >> None of this is necessary if you simply call
> Request.getUserPrincipal,
> >> which is why sf does that.
> >
> > Then you get a JbossGenericPrincipal instance as shown above and not
> my user principal instance.
> 
> 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.

> What is the difference between a "full principal" and whatever you
> think
> you're getting instead of that?
> 
> >> If you are trying to protect against users masking the UserPrincipal
> by
> >> re-wrapping the request, there are other techniques that will work
> and
> >> are more appropriate IMO.
> >
> > No, that's not the purpose at all especially since getPrincipal is
> > also public. That should maybe be protected though.
> 
> I still don't see the point of adding this method at all.

For the JBossRealm it's not necessary to use SecurityRequestWrapper as the necessary fields are set by security framework in the original request. 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.

> >>> SecurityFilter
> >>> Call isUserInRole(String) on the wrapped request instead of
> directly
> >>> on the realm
> >>
> >> I think this probably makes sense. I'll have to look more closely at
> >> your patch and the code to figure out why we decided to call the
> realm
> >> directly: it's probably because the default isUserInRole method
> simply
> >> returns false.
> >
> > I changed it because in an earlier attempt to solve the problem it
> > was
> > needed to do so. In the final implementation it's not necessary as
> what
> > it does is to call the realm. A proper implementation would be that
> it
> > call isUserInRole on the underlying request, and that works with the
> > JBossRealm but I thought it might be problems with other Realm
> > implementations so I kept that requestwrapper calls hasUserRole (or
> > whatever the method name is) on the SecurityfilterRealm instance and
> in
> > JBossRealm I call the underlying request instance there.
> 
> Okay. Given that this is a security-related project, please keep your
> patches to a minimum. While I appreciate the patch, I'm not interested
> in getting the last 6 months of your tinkering-around with sf all at
> once. If you find a problem, demonstrate it, fix it, and submit the
> patch (including test cases).
>
> > That SecurityFilter call isUserInRole on request wrapper instead of
> > directly on realm makes it consistent with how an application calls
> it.
> 
> This seems like a reasonable change: the filter should call the
> request's isUserInRole method, which already delegates to the realm.
> I'll have to ask Max why he's done that.
> 
> >> Why did you remove the no-arg constructor for SimplePrincipal? The
> >> class is serializable and therefore must have a no-arg constructor.
> >
> > That is not correct
> 
> You're right: I was thinking that SimplePrincipal was being subclassed
> by other classes in sf. It's not: it's probably being subclassed by
> others, though, but you're right: the private constructor is not
> particularly useful.

It's not a problem if it's being subclassed. The only time a class, in this context, has to have an accessible no-arg constructor is if it is NOT serializable and a SUBCLASS wants to be serializable. Then all parent NON-serializable classes must have an accessible no-arg constructor.
 
> >>> In addition I removed all compiler warnings and wildcard imports in
> >>> all classes.
> >>>
> >>> It’s also needed to update catalina.jar to version 5.5.10 or newer
> >> and
> >>> add jboss-web-service.jar (I believe it was named jbossweb-
> >> service.jar
> >>> in 4.2.3 then jboss-web-service.jar from 5.0)
> >>>
> >>> The patch can be found at
> >>> http://www.abrahamsson.com/securityfilter.patch
> >>
> >> This patch cannot be accepted in its current form. In order to
> accept,
> >> you'll need to:
> >>
> >> 1. Remove all classes where no code was changed. I appreciate the
> re-
> >> formatting of the imports that your IDE performs, but we're not
> going
> >> to mass-patch files just for the sake of re-ordering import
> statements.
> >
> > The reason was not to re-format the imports but to remove all
> > wildcard imports, which are not good practice, and to remove unused.
> > It was then easiest to remove all imports where that was the case and
> > let Eclipse add them automatically.
> 
> I wouldn't say that using wildcard imports is "not good practice". The
> reality is that I'd rather not change classes that don't need changes.

The classical example of why wildcard imports are bad is this:

In jdk 1.1 it was perfectly ok to do like this:
import java.awt.*;
import java.util.*;

Compile the same code with jdk 1.2 will break, as it adds java.util.List that will then collide with java.awt.List. While that is a very old case, there is no guarantee that future jdk's will not add new classes that will break your code because of your wildcard imports.

> >> 3. Provide unit tests that demonstrate any problems with the current
> >> code and prove that your changes fix those problems.
> >
> > The problem can be trivially shown by
> > 1) SecurityFilter can't authenticate properly on JBoss container
> > 2) The principal that is returned by JBoss is an instance of
> > GenericPrincipal. It's needed that the request wrapper handles
> > extracting the user principal from it when calling getUserPrincipal()
> 
> sf tries to stay decoupled from other APIs. You'll notice that the only
> place GenericPrincipal is used is in the TrivialCatalinaRealm, which is
> separate from the main code (in examples). Likewise, the
> CatalinaRealmAdapter is in a separate set of packages from the main
> code. We're not going to re-write SecurityRealmWrapper to create a
> dependency on o.a.c.r.GenericPrincipal.
> 
> If you want to create a JBossRealmAdapter (or just use the
> CatalinaRealmAdapter directory), you're more than welcome to do so.

In the patch referenced to above it is in its own directory.
 
> > That is the actual code change, the rest is just removing compiler
> > warnings and wildcard imports which is good coding practice.
> 
> What if I told you that good coding practice was putting your curly
> braces in different places? Let's not treat opinions as facts.

Where you put your curly braces doesn't affect the compiled code. I've seen and solved bugs, real bugs, that would have been avoided if the programmer had taken warnings seriously. As you point out above, this is a security related project...
 
> >> 4. Remove the serialVersionId from SavedRequest (it's not
> necessary),
> >> which removes the whole class from the patch due to #1 above.
> Actually,
> >> remove all serialVersionIds from all files in the patch.
> >
> > Serializable classes without serialVersionUID gives a compiler
> warning.
> 
> It gives a warning from your IDE.

It gives a warning if you compile with jdk 1.5 or later
 
> > From javadoc: "However, it is strongly recommended that all
> serializable
> > classes explicitly declare serialVersionUID values"
> >
> > Hence it's good practice to have it there (although not strictly
> > needed)
> 
> What if we don't want different versions of our objects to be
> compatible
> when de-serialized? Setting the serialVersionID leave you one more
> thing
> to remember if/when you modify a class: change the serialVersionUID.
> 
> If you're looking to conduct a class on code cleanliness, you've come
> to
> the wrong place. If you're got something to offer (which it looks like
> you do), please do so. I think the best thing for you to do, here, is
> to
> use a custom realm and/or request wrapper that un-wraps the "user"
> Principal from your GenericPrincipal object. This way, the main sf code
> does not have to change.
> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkvW/a0ACgkQ9CaO5/Lv0PCgNgCgw25wOrhEM2OCowxt9pRbddru
> HpwAn38cp0dHeXs/7jJxyOMKdkJES4xM
> =J7lE
> -----END PGP SIGNATURE-----

Re: [securityfilter-devel] Securityfilter + JBoss

[Christopher S. <ch...@ch...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sverker,

No need to reply to both me and the list: I am subscribed to it.

On 4/26/2010 6:53 PM, Sverker Abrahamsson wrote:
> Correct, Request is the internal Catalina class for which they 
> provide a wrapper. The reason for this is that the Principal returned
> by JBoss is a JBossGenericPrincipal so that is what is set as
> principal in your wrapper, I believe it's the same for pure Tomcat as
> well. To get the User Principal from that you need to call
> principal.getUserPrincipal(). That is why I check if the principal is
> an instance of GenericPrincipal and if so return the actual User
> Principal.
> 
> The reference to Tomcat Request here was just to show that internally Tomcat do the same

My question was: why should we change anything at all? What is the
problem with the current implementation?

>>> If the Pincipal is an instance of
>>> GenericPrincipal then it’s necessary to call getUserPrincipal on the
>>> Principal to get the UserPrincipal. Also added a getPrincipal method
>>> which is used internally where the full Principall is needed.
>>
>> None of this is necessary if you simply call Request.getUserPrincipal,
>> which is why sf does that.
> 
> Then you get a JbossGenericPrincipal instance as shown above and not my user principal instance.

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?

What is the difference between a "full principal" and whatever you think
you're getting instead of that?

>> If you are trying to protect against users masking the UserPrincipal by
>> re-wrapping the request, there are other techniques that will work and
>> are more appropriate IMO.
> 
> No, that's not the purpose at all especially since getPrincipal is
> also public. That should maybe be protected though.

I still don't see the point of adding this method at all.

>>> SecurityFilter
>>> Call isUserInRole(String) on the wrapped request instead of directly
>>> on the realm
>>
>> I think this probably makes sense. I'll have to look more closely at
>> your patch and the code to figure out why we decided to call the realm
>> directly: it's probably because the default isUserInRole method simply
>> returns false.
> 
> I changed it because in an earlier attempt to solve the problem it
> was
> needed to do so. In the final implementation it's not necessary as what
> it does is to call the realm. A proper implementation would be that it
> call isUserInRole on the underlying request, and that works with the
> JBossRealm but I thought it might be problems with other Realm
> implementations so I kept that requestwrapper calls hasUserRole (or
> whatever the method name is) on the SecurityfilterRealm instance and in
> JBossRealm I call the underlying request instance there.

Okay. Given that this is a security-related project, please keep your
patches to a minimum. While I appreciate the patch, I'm not interested
in getting the last 6 months of your tinkering-around with sf all at
once. If you find a problem, demonstrate it, fix it, and submit the
patch (including test cases).

> That SecurityFilter call isUserInRole on request wrapper instead of
> directly on realm makes it consistent with how an application calls it.

This seems like a reasonable change: the filter should call the
request's isUserInRole method, which already delegates to the realm.
I'll have to ask Max why he's done that.

>> Why did you remove the no-arg constructor for SimplePrincipal? The
>> class is serializable and therefore must have a no-arg constructor.
> 
> That is not correct

You're right: I was thinking that SimplePrincipal was being subclassed
by other classes in sf. It's not: it's probably being subclassed by
others, though, but you're right: the private constructor is not
particularly useful.

>>> In addition I removed all compiler warnings and wildcard imports in
>>> all classes.
>>>
>>> It’s also needed to update catalina.jar to version 5.5.10 or newer
>> and
>>> add jboss-web-service.jar (I believe it was named jbossweb-
>> service.jar
>>> in 4.2.3 then jboss-web-service.jar from 5.0)
>>>
>>> The patch can be found at
>>> http://www.abrahamsson.com/securityfilter.patch
>>
>> This patch cannot be accepted in its current form. In order to accept,
>> you'll need to:
>>
>> 1. Remove all classes where no code was changed. I appreciate the re-
>> formatting of the imports that your IDE performs, but we're not going
>> to mass-patch files just for the sake of re-ordering import statements.
> 
> The reason was not to re-format the imports but to remove all 
> wildcard imports, which are not good practice, and to remove unused.
> It was then easiest to remove all imports where that was the case and
> let Eclipse add them automatically.

I wouldn't say that using wildcard imports is "not good practice". The
reality is that I'd rather not change classes that don't need changes.

>> 3. Provide unit tests that demonstrate any problems with the current
>> code and prove that your changes fix those problems.
> 
> The problem can be trivially shown by
> 1) SecurityFilter can't authenticate properly on JBoss container
> 2) The principal that is returned by JBoss is an instance of
> GenericPrincipal. It's needed that the request wrapper handles
> extracting the user principal from it when calling getUserPrincipal()

sf tries to stay decoupled from other APIs. You'll notice that the only
place GenericPrincipal is used is in the TrivialCatalinaRealm, which is
separate from the main code (in examples). Likewise, the
CatalinaRealmAdapter is in a separate set of packages from the main
code. We're not going to re-write SecurityRealmWrapper to create a
dependency on o.a.c.r.GenericPrincipal.

If you want to create a JBossRealmAdapter (or just use the
CatalinaRealmAdapter directory), you're more than welcome to do so.

> That is the actual code change, the rest is just removing compiler
> warnings and wildcard imports which is good coding practice.

What if I told you that good coding practice was putting your curly
braces in different places? Let's not treat opinions as facts.

>> 4. Remove the serialVersionId from SavedRequest (it's not necessary),
>> which removes the whole class from the patch due to #1 above. Actually,
>> remove all serialVersionIds from all files in the patch.
> 
> Serializable classes without serialVersionUID gives a compiler warning.

It gives a warning from your IDE.

> From javadoc: "However, it is strongly recommended that all serializable
> classes explicitly declare serialVersionUID values"
>
> Hence it's good practice to have it there (although not strictly
> needed)

What if we don't want different versions of our objects to be compatible
when de-serialized? Setting the serialVersionID leave you one more thing
to remember if/when you modify a class: change the serialVersionUID.

If you're looking to conduct a class on code cleanliness, you've come to
the wrong place. If you're got something to offer (which it looks like
you do), please do so. I think the best thing for you to do, here, is to
use a custom realm and/or request wrapper that un-wraps the "user"
Principal from your GenericPrincipal object. This way, the main sf code
does not have to change.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvW/a0ACgkQ9CaO5/Lv0PCgNgCgw25wOrhEM2OCowxt9pRbddru
HpwAn38cp0dHeXs/7jJxyOMKdkJES4xM
=J7lE
-----END PGP SIGNATURE-----

Re: [securityfilter-devel] Securityfilter + JBoss

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

> -----Original Message-----
> From: Christopher Schultz [mailto:ch...@ch...]
> Sent: den 26 april 2010 4:59
> To: Sverker Abrahamsson
> Subject: Re: [securityfilter-devel] Securityfilter + JBoss
> 
> Sverker,
> 
> On 4/25/2010 4:43 PM, Sverker Abrahamsson wrote:
> > Anyway, I soon remembered why I had been using Securityfilter as it
> > was impossible  to make the standard procedures to work as I wanted.
> 
> That's typically why most people go with sf.
> 
> > There were some small changes needed to other classes as described
> below:
> >
> > SecurityRequestWrapper
> > getUserPrincipal was changed to be in line with
> > org.apache.catalina.connector.Request.
> 
> o.a.c.c.Request is a non-standard class. SecurityRequestWrapper wraps
> HttpServletRequest and doesn't know anything about Tomcat's "Request"
> object, and I'd like to keep it that way.

Correct, Request is the internal Catalina class for which they provide a wrapper. The reason for this is that the Principal returned by JBoss is a JBossGenericPrincipal so that is what is set as principal in your wrapper, I believe it's the same for pure Tomcat as well. To get the User Principal from that you need to call principal.getUserPrincipal(). That is why I check if the principal is an instance of GenericPrincipal and if so return the actual User Principal.

The reference to Tomcat Request here was just to show that internally Tomcat do the same
 
> > If the Pincipal is an instance of
> > GenericPrincipal then it’s necessary to call getUserPrincipal on the
> > Principal to get the UserPrincipal. Also added a getPrincipal method
> > which is used internally where the full Principall is needed.
> 
> None of this is necessary if you simply call Request.getUserPrincipal,
> which is why sf does that.

Then you get a JbossGenericPrincipal instance as shown above and not my user principal instance.

> If you are trying to protect against users masking the UserPrincipal by
> re-wrapping the request, there are other techniques that will work and
> are more appropriate IMO.

No, that's not the purpose at all especially since getPrincipal is also public. That should maybe be protected though.
 
> > SecurityFilter
> > Call isUserInRole(String) on the wrapped request instead of directly
> > on the realm
> 
> I think this probably makes sense. I'll have to look more closely at
> your patch and the code to figure out why we decided to call the realm
> directly: it's probably because the default isUserInRole method simply
> returns false.

I changed it because in an earlier attempt to solve the problem it was needed to do so. In the final implementation it's not necessary as what it does is to call the realm. A proper implementation would be that it call isUserInRole on the underlying request, and that works with the JBossRealm but I thought it might be problems with other Realm implementations so I kept that requestwrapper calls hasUserRole (or whatever the method name is) on the SecurityfilterRealm instance and in JBossRealm I call the underlying request instance there.

That SecurityFilter call isUserInRole on request wrapper instead of directly on realm makes it consistent with how an application calls it.
 
> Why did you remove the no-arg constructor for SimplePrincipal? The
> class is serializable and therefore must have a no-arg constructor.

That is not correct, this is what javadoc says on Serializable:

"The subtype may assume this responsibility only if the class it extends has an accessible no-arg constructor to initialize the class's state" and "During deserialization, the fields of non-serializable classes will be initialized using the public or protected no-arg constructor of the class. A no-arg constructor must be accessible to the subclass that is serializable. The fields of serializable subclasses will be restored from the stream."

It is only the case that a class have to have an _accessible_ no-arg constructor if it is not Serializable and a subclass is to be able to be Serializable. A private constructor doesn't help nor is it needed on a class which is Serializable itself.

I removed it to remove a compiler warning. It is good practice to eliminate all compiler warnings as they might hide real errors.
 
> > In addition I removed all compiler warnings and wildcard imports in
> > all classes.
> >
> > It’s also needed to update catalina.jar to version 5.5.10 or newer
> and
> > add jboss-web-service.jar (I believe it was named jbossweb-
> service.jar
> > in 4.2.3 then jboss-web-service.jar from 5.0)
> >
> > The patch can be found at
> > http://www.abrahamsson.com/securityfilter.patch
> 
> This patch cannot be accepted in its current form. In order to accept,
> you'll need to:
> 
> 1. Remove all classes where no code was changed. I appreciate the re-
> formatting of the imports that your IDE performs, but we're not going
> to mass-patch files just for the sake of re-ordering import statements.

The reason was not to re-format the imports but to remove all wildcard imports, which are not good practice, and to remove unused. It was then easiest to remove all imports where that was the case and let Eclipse add them automatically.
 
> 2. Turn on "whitespace equivalence" in your diff program so that it
> doesn't report that entire methods have changed when only certain
> portions of those methods have changed.

Ok, I'll see how to do that. Eclipse created that file automatically. I agree that changes in amount of whitespaces should not render a patch.
 
> 3. Provide unit tests that demonstrate any problems with the current
> code and prove that your changes fix those problems.

The problem can be trivially shown by
1) SecurityFilter can't authenticate properly on JBoss container
2) The principal that is returned by JBoss is an instance of GenericPrincipal. It's needed that the request wrapper handles extracting the user principal from it when calling getUserPrincipal()

That is the actual code change, the rest is just removing compiler warnings and wildcard imports which is good coding practice.
 
> 4. Remove the serialVersionId from SavedRequest (it's not necessary),
> which removes the whole class from the patch due to #1 above. Actually,
> remove all serialVersionIds from all files in the patch.

Serializable classes without serialVersionUID gives a compiler warning. >From javadoc: "However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values"

Hence it's good practice to have it there (although not strictly needed)
 
> I'm not convinced that any of the changes you've made are required. I
> appreciate the contribution of the JBossRealm (really
> WebAuthenticationRealm) and we'll consider including it in sf.
> Meanwhile, you could post the complete code to the forums so that
> others in a similar environment can use your code before inclusion into
> the trunk.
> 
> Thanks,
> -chris

[securityfilter-devel] Securityfilter + JBoss

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

Hello,
I’ve been using Securityfilter in a project since long time back, now when I
was doing some maintenance I thought I’d change it to use standard form
based login as I never had got Securityfilter to work really well with
JBoss. It has been working more or less but never perfect.

Anyway, I soon remembered why I had been using Securityfilter as it was
impossible  to make the standard procedures to work as I wanted. So I went
back to have a new look at Securityfilter, my old version was a modified
1.x. After some research I found out that since JBoss 4.2.3 there is a class
called WebAuthentication which can be used to programmatically authenticate
in the web layer.

I’ve created a class JBossRealm which can be used to authenticate to JBoss.
It make use of WebAuthentication to authenticate to the JBoss security
container. There is a bug which is reported in
https://jira.jboss.org/jira/browse/JBAS-5549 which cause that the
authenticated context is “forgotten” between each request unless there is a
security-constraint in web.xml, as described in jira just add a dummy entry
like this:

<security-constraint>
  <web-resource-collection>
    <web-resource-name>dummy</web-resource-name>
    <url-pattern>/dummy/*</url-pattern>
  </web-resource-collection>
</security-constraint>

There were some small changes needed to other classes as described below:

SecurityRequestWrapper
getUserPrincipal was changed to be in line with
org.apache.catalina.connector.Request. If the Pincipal is an instance of
GenericPrincipal then it’s necessary to call getUserPrincipal on the
Principal to get the UserPrincipal. Also added a getPrincipal method which
is used internally where the full Principall is needed.

FormAuthenticator
Use getPrincipal() on SecurityRequestWrapper instead of getUserPrincipal()

SecurityFilter
Call isUserInRole(String) on the wrapped request instead of directly on the
realm

In addition I removed all compiler warnings and wildcard imports in all
classes.

It’s also needed to update catalina.jar to version 5.5.10 or newer and add
jboss-web-service.jar (I believe it was named jbossweb-service.jar in 4.2.3
then jboss-web-service.jar from 5.0)

The patch can be found at http://www.abrahamsson.com/securityfilter.patch

Best regards
Sverker

Re: [securityfilter-devel] Early authorization in sf

[Christopher S. <ch...@ch...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

Christopher Schultz wrote:
| So, "early authorization" is, in fact, not early at all (I had been
| using a method that is called before the authentication to determine if
| the request is authorized before any additional processing occurs).
| Thus, all authorization may be performed /after/ authentication.

I just realized that some stuff needs to be performed early:

- - transport-guarantee check
- - short-circuit of "no roles" checking for a security-constraint
~  (auto-constraint with no defined roles => forbidden)

Unless one of those things occurs, processing will continue with
authentication.

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhRHlIACgkQ9CaO5/Lv0PBw6QCgovzYpI+FP1MFPnvDts+717dF
gUYAn145Y9G52RZ+aqjRd6M90T+vftn7
=3mC8
-----END PGP SIGNATURE-----

[securityfilter-devel] Early authorization in sf

[Christopher S. <ch...@ch...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

I'm working on re-architecting sf so that it is easier to understand,
and more extensible.

I've been looking at section 12.7.3 of the servlet specification (v2.5)
which says that missing <security-constraint> or <auth-constraint>
constraints on a particular request mean that the request should be
authorized.

Since sf allows authentication at any time, should this "early
authorization" trump the need for authentication at all? I'm guessing
"no". That would prevent authentication from occurring unless
constraints were placed on the URL being requested, which is probably
not intended at all.

So, if there is no security-constraint or no auth-constraint, then the
request will be considered authorized. If the request contains
authentication information (according to one of the authenticators, of
course), then we will process it. If authentication fails, we will take
appropriate action depending on the type of authentication (BASIC,
DIGEST, FORM, or CLIENT-CERT).

So, "early authorization" is, in fact, not early at all (I had been
using a method that is called before the authentication to determine if
the request is authorized before any additional processing occurs).
Thus, all authorization may be performed /after/ authentication.

Does that all sounds right?

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhRGx4ACgkQ9CaO5/Lv0PBbYQCfSUwsyC7ydEpK0GuDZMbYua6Y
LyAAn3ZHJBnHv8NNM9Ajq5UZ/wiOJ4eV
=YLOq
-----END PGP SIGNATURE-----

[securityfilter-devel] Choosing a matching security-constraint

[Christopher S. <ch...@ch...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

I've been looking at the url-pattern matching code in securityfilter,
attempting to simplify it a bit, and making sure that it matches the 2.5
specification.

I think we may have a problem with interpretation of section 12.7.3:

"
SRV.12.7.3 Processing Requests

When a Servlet container receives a request, it shall use the algorithm
described in SRV.11.1 to select the constraints (if any) defined on the
url-pattern that is the best match to the request URI. If no constraints
are selected, the container shall accept the request. Otherwise the
container shall determine if the HTTP method of the request is
constrained at the selected pattern. If it is not, the request shall be
accepted. Otherwise, the request must satisfy the constraints that apply
to the http-method at the url-pattern. Both of the following rules must
be satisfied for the request to be accepted and dispatched to the
associated servlet.
"

I read this to mean "select the security constraint based solely upon
the best url-pattern match". After that, if none of the http-methods for
that web-resource-collection match, the request is accepted with no
further security constraints.

Honestly, that doesn't seem like a good idea, but it sounds like it
matches the specification.

In the current implementation, we match url-pattern and http-method at
the same time, so if they don't /both/ match, we continue looking for
another web-resource-collection that /does/ match.

Does anyone have any comments on this?

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgYgVMACgkQ9CaO5/Lv0PCZkQCfbCm1au9k2XjjvED71jLlgmAh
qSIAnRcrK34wWRXDX8nL+7hxzrIQrzdf
=mMyy
-----END PGP SIGNATURE-----

Re: [securityfilter-devel] New feature proposal: IP address fixing

[Christopher S. <ch...@ch...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

Christopher Schultz wrote:
| I'm considering adding another feature to the 2.x version of
| securityfilter. Let me know what you think.
|
| Some web sites allow you to enable "IP address checking" or something
| sounding like that. Basically, your session will be tied to your IP
| address for extra security. That way, even if someone can guess your
| session id and submit it along with a request, they can't hijack your
| session.

After implementing this, I'm starting to think that maybe it would be
better to implement it separately (say, as a completely separate Filter).

First, it's entirely orthogonal to both authentication and authorization
(which is what sf is really for). Second, it requires additional
processing of every request, which results in a (small) performance hit.
Even offering this as an optional feature requires checking a flag for
whether we should perform the check, etc.

Honestly, I think this kind of pollutes sf. The only reason I was even
considering it was because it sort of goes along with authorization, but
in a completely different way.

I'm not entirely objecting to inclusion in the project... I just think
it should probably be put into a separate Filter that can be configured
completely separately from the main sf Filter.

Any thoughts?

Thanks,
- -chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkfZv6cACgkQ9CaO5/Lv0PBCTQCgsCzHD4ht/wU9gEUfrFHPRcUK
amIAnAwkV44XHmbYDglazcudX0/MGyNW
=aSdv
-----END PGP SIGNATURE-----

Re: [securityfilter-devel] New feature proposal: IP address fixing

[Torgeir V. <to...@po...>]

On 13 Dec 2007, at 07:55, Christopher Schultz wrote:

> I'm considering adding another feature to the 2.x version of
> securityfilter. Let me know what you think.
>
> Some web sites allow you to enable "IP address checking" or something
> sounding like that. Basically, your session will be tied to your IP
> address for extra security. That way, even if someone can guess your
> session id and submit it along with a request, they can't hijack your
> session.


+1 provided that it's plug-able like the remember me functionality.

-- 
Torgeir Veimo
to...@po...

Re: [securityfilter-devel] New feature proposal: IP address fixing

[Max C. <ma...@ma...>]

I think it would be wise to check for a specific value of the
parameter, so that the behavior isn't surprising if someone implements
a drop-down for it, the user picks "no", and then gets IP checking
anyway. Perhaps accept "1", "true", and "yes" case-insensitively to
turn it on, otherwise it's off. I don't recall what values the
"remember me" feature accepts, but this new feature should be
consistent.

-Max

On 12/12/07, Christopher Schultz <ch...@ch...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> I'm considering adding another feature to the 2.x version of
> securityfilter. Let me know what you think.
>
> Some web sites allow you to enable "IP address checking" or something
> sounding like that. Basically, your session will be tied to your IP
> address for extra security. That way, even if someone can guess your
> session id and submit it along with a request, they can't hijack your
> session.
>
> This will, or course, be optional to the user using the website. Some
> services like AOL use proxies for dialup traffic and that really screws
> things up when it comes to IP validation.
>
> My plan is simply to store the remote user's IP address in the session
> and check against that as part of the authorization step (actually, it's
> before the authorization, but after authentication because that is tied
> to the realm, and I'd like to do this checking in a single place).
>
> I'll invent a default check-ip-address request parameter name and make
> it changeable via either a filter config-param or through the XML
> configuration file. (I think for sf 2.0 I'll go with a filter config
> param and for a future version, I'll go for an XML element, but comments
> are appreciated).
>
> If that parameter has any value during login (or a specific value... I'd
> appreciate some feedback here), then we'll turn on this feature for the
> current session, and it will stay enabled until the session expires.
>
> Any feedback on this is certainly welcome.
>
> Thanks,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHYFjD9CaO5/Lv0PARAvmKAKCI4cxucH9etBBZY4iNeC9233zh/QCdFDz/
> 6vUFFPlvLvJhVTw+zJDOCOk=
> =xVCt
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> securityfilter-devel mailing list
> sec...@li...
> https://lists.sourceforge.net/lists/listinfo/securityfilter-devel
>

[securityfilter-devel] New feature proposal: IP address fixing

[Christopher S. <ch...@ch...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

I'm considering adding another feature to the 2.x version of
securityfilter. Let me know what you think.

Some web sites allow you to enable "IP address checking" or something
sounding like that. Basically, your session will be tied to your IP
address for extra security. That way, even if someone can guess your
session id and submit it along with a request, they can't hijack your
session.

This will, or course, be optional to the user using the website. Some
services like AOL use proxies for dialup traffic and that really screws
things up when it comes to IP validation.

My plan is simply to store the remote user's IP address in the session
and check against that as part of the authorization step (actually, it's
before the authorization, but after authentication because that is tied
to the realm, and I'd like to do this checking in a single place).

I'll invent a default check-ip-address request parameter name and make
it changeable via either a filter config-param or through the XML
configuration file. (I think for sf 2.0 I'll go with a filter config
param and for a future version, I'll go for an XML element, but comments
are appreciated).

If that parameter has any value during login (or a specific value... I'd
appreciate some feedback here), then we'll turn on this feature for the
current session, and it will stay enabled until the session expires.

Any feedback on this is certainly welcome.

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYFjD9CaO5/Lv0PARAvmKAKCI4cxucH9etBBZY4iNeC9233zh/QCdFDz/
6vUFFPlvLvJhVTw+zJDOCOk=
=xVCt
-----END PGP SIGNATURE-----

[securityfilter-devel] (no subject)

[securityfilter-devel] (no subject)

[securityfilter-devel] transport-guarantee is in

[Christopher S. <ch...@ch...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

For anyone who is interested, transport-guarantee is now properly
handled in sf. Get a copy of the trunk if you're interested in testing
it out. Unit tests included (of course!).

The port used for SSL redirection is 443 by default, but you can change
it by setting the "ssl-redirect-port" filter init parameter. If you set
it to a negative number, you will disable ssl-upgrade redirection
(you'll get a FORBIDDEN response instead).

Fortunately, the existing securityfilter DTD included the required
entries for <transport-guarantee>, so there's no new DTD required.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMfUf9CaO5/Lv0PARAkepAKCid+OLEAJMSvpZHFgdtEwUYx+aYQCfSmfp
bD65F+nBqXaBvKBPFDtLKQE=
=b8f6
-----END PGP SIGNATURE-----

Re: [securityfilter-devel] transport-guarantee secure port configuration

[Max C. <ma...@ma...>]

#3 looks like a good option to me as well. It has an additional feature of
being app-wide, which would allow other elements in the system to use the
parameter to construct URLs using the port if they want to. Also, I agree
that ports other than 443 are unlikely on production servers, they are
fairly common on development servers, adding some importance to making it
configurable.



Another aspect of redirecting is that a lot of sites are setup using lousy
web server plugins or just a simple proxy, where redirects are not properly
rewritten. Here's an illustration of the problem:
1. user's browser requests GET http://www.company.com/
2. (web server on www.company.com proxies request to
internal-server.company.com)
3. (internal-server.company.com requires https, and redirects to
https://internal-server.company.com:443/)
4. user's browser requests (in response to the redirect) GET
https://internal-server.company.com:443/ and fails because the server is
unreachable from the outside
This won't happen with a properly setup server configuration, but it has
been my experience that it is fairly common for organizations to have this
problem. Maybe things have gotten better since I was working in this space,
but I doubt it. So, it might be a useful feature to allow securityfilter to
be configured with a full "https://www.company.com:443/"-style absolute
prefix for the redirects. The absolute prefix could be an advantage over the
redirect functionality offered by the containers, for teams with lousy
server setups. It does create some issues for app developers during
development, when they won't want requests to their dev server to redirect
to their public server, but they can handle this with their own app
configuration / build systems. And we should also allow just the port to
change, to avoid creating headaches for those that do have their servers
setup well. Solving this configuration problem is out of scope for
securityfilter to deal with, but I wanted to raise awareness of the issue in
case you decide to support the configuration of a "
https://www.company.com:443/"-style prefix.

To recap:
1. we should support just configuring the port
a) so it can be set to something other than 443, which is common on dev
servers
b) so those that have their production servers setup properly don't have to
deal with configuring an absolute prefix
2. (optional) it may be additionally useful to support the configuration of
an absolute prefix so that the redirects can work with lousy server configs

I collaborated on the design of another project called SSLExt (
http://sslext.sf.net) that worked with Struts, allowing developers to set a
flag for each action to indicate that it should only execute when the
request was over https. Ideally, developers would use the URL rewriting tags
so that the URLs would be constructed to hit the https port without needing
a redirect. However, it would also redirect requests received over plain
http for those actions (that may have been optionally configurable, but I
don't remember precisely what the final implementation does). One
undesireable aspect of the redirects was that it could send the confidential
form data over the wire again. So, sloppy usage could result in confidential
data being sent over the wire twice (orig request, redirect response), and
it might not be that obvious to developers when this happens. Another
important aspect of this is that the data can get stuck in browser history,
since a redirect cannot cause a POST and the only other alternative besides
keeping the data on the server or just failing is to create a redirect with
the data in the query string -- a troubling alternative from a security
standpoint.

I don't recall what containers (such as tomcat) do in response to plain http
requests for urls with transport-guarantee settings that require https, but
I think we should try to do the same. Or punt a bit on the first
implementation and just fail fast rather than sending the info over the wire
again. If the container does something fancy like keep the data on the
server and this turns out to be difficult to implement (securely), I think
failing is better than sending the data over the wire again.

-Max

On 11/6/07, Torgeir Veimo <to...@po...> wrote:
>
>
> On 6 Nov 2007, at 22:59, Christopher Schultz wrote:
>
> > On the one hand, it's nice to have configuration in a single place
> > (like
> > securityfilter-config.xml). On the other hand, that file should be as
> > much like the deployment descriptor's security-constraint sections as
> > possible.
> >
> > I wondered if anyone had any thoughts on which strategy would be best.
> > I'm leaning toward #3.
>
>
> +1. I'd go for #3 as well. Setting the SL port to something else than
> 443 I'd say would happen very rarely.
>
> --
> Torgeir Veimo
> to...@po...
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> securityfilter-devel mailing list
> sec...@li...
> https://lists.sourceforge.net/lists/listinfo/securityfilter-devel
>

Re: [securityfilter-devel] transport-guarantee secure port configuration

[Torgeir V. <to...@po...>]

On 6 Nov 2007, at 22:59, Christopher Schultz wrote:

> On the one hand, it's nice to have configuration in a single place  
> (like
> securityfilter-config.xml). On the other hand, that file should be as
> much like the deployment descriptor's security-constraint sections as
> possible.
>
> I wondered if anyone had any thoughts on which strategy would be best.
> I'm leaning toward #3.


+1. I'd go for #3 as well. Setting the SL port to something else than  
443 I'd say would happen very rarely.

-- 
Torgeir Veimo
to...@po...

[securityfilter-devel] transport-guarantee secure port configuration

[Christopher S. <ch...@ch...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

Okay, I've got an implementation of the <user-data-constraint> and
<transport-guarantee> support built and working. Now all I need to do is
add configuration for the target SSL port to use.

I basically have three options:

1. Add an optional attribute to an existing element in
   securityfilter-config.xml like <transport-guarantee sslport="123">

2. Add a new element to securityfilter-config.xml like
   <ssl-port>123</ssl-port>

3. Add a configuration parameter in web.xml for the filter itself.
   <filter>
      ...
      <init-param>
         <description>
            The port number to use when upgrading to an SSL connection
            to fulfill a transport-guarantee of INTEGRAL or
            CONFIDENTIAL.
         </description>
         <param-name>sslPort</param-name>
         <param-value>123</param-value>
      </init-param>

On the one hand, it's nice to have configuration in a single place (like
securityfilter-config.xml). On the other hand, that file should be as
much like the deployment descriptor's security-constraint sections as
possible.

I wondered if anyone had any thoughts on which strategy would be best.
I'm leaning toward #3.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMPHF9CaO5/Lv0PARAus9AJ9Q5KwbHQoOoKrqiJKdpKZb0sP6IgCfQEJ8
CXH1qDzIAUqeRnrubSebomg=
=qa2U
-----END PGP SIGNATURE-----

Re: [securityfilter-devel] Securityfilter Improvements

[Christopher S. <ch...@ch...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ivan,

Ivan Latysh wrote:
> I mean HttpRequest, because:

I still don't get it. What is HttpRequest?

> "Method PROPFIND is not defined in RFC 2068 and is not supported by the Servlet 
> API."

I see. How does WebdavServlet get around this problem?

> Servlet does not handle PROPFIND and some other types of request ...

Does the container throw an exception when PROPFIND is the method? Or,
does the servlet have to implement service(ServletRequest,
ServletResponse) and look for that particular method?

> And WebDAV: ... WebdavServlet extends HttpServlet ...
> 
> WebDAV security is a bitch, so if SF can handle such things you will bring some 
> users on-board.

Well, we're just a filter. If the container is objecting to certain
requests, there's nothing we can do about it.

Doesn't Tomcat support BASIC auth to protect the WebdavServlet? Or, is
all of the authentication and authorization for WebDAV built into the
WebdavServlet?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHL2j09CaO5/Lv0PARAoCxAKCLKMGgnn69NYVezyXZuhkkfNHLbgCggyQu
ZjI+HMASjOBZjUkq5QJNcFE=
=2AOv
-----END PGP SIGNATURE-----

Re: [securityfilter-devel] Securityfilter Improvements

[Ivan L. <Iva...@ya...>]

Christopher Schultz wrote:

>> Wish-list:
>> Support HttpRequest not only HttpServletRequest, so SF can be used with
>> WebDAV.
> 
> Do you mean that you want us to support ServletRequest and not just
> HttpServletRequest? That might be a problem with the current
> architecture, since we use the HttpSession (needs http heh heh heh) to
> store the Principal object. WebDAV should always go over HTTP, though,
> so I'm not sure why securityfilter + BASIC auth wouldn't work for WebDAV.
> 
> Can you help me understand what we're missing?
I mean HttpRequest, because:
"Method PROPFIND is not defined in RFC 2068 and is not supported by the Servlet 
API."

Servlet does not handle PROPFIND and some other types of request ...

And WebDAV: ... WebdavServlet extends HttpServlet ...

WebDAV security is a bitch, so if SF can handle such things you will bring some 
users on-board.

-- 
Ivan Latysh
Iva...@ya...

Re: [securityfilter-devel] Securityfilter Improvements

[Ivan L. <Iva...@ya...>]

Ivan Latysh wrote:
Sorry, it was intended to the list.

  Christopher Schultz wrote:

  [skipped]
> * Re-architect the filter to be mode modular - I've been looking at
> Struts 1's RequestProcessor (as per the "better extensibility" bug
> filed) and Struts 2's "interceptor" stack as two different possible
> models for modularization
  Modularization is a good idea, but in case you are thinking to bring
  struts on board, pleas don't, servlet framework is sufficient enough for
  the project.

  I would keep core SF as a filter and extend it when extensions needed,
  and provide the basic extension, so it can be used out of the box when
  fits, or used as a reference when developer want to extend `more`.

> * Add support for DIGEST authentication (requires change to Realm 
> interface)
> * Add support for CLIENT-CERT authentication

  Wish-list:
  Support HttpRequest not only HttpServletRequest, so SF can be used with
  WebDAV.


-- 
Ivan Latysh
Iva...@ya...

Re: [securityfilter-devel] Securityfilter Improvements

[Christopher S. <ch...@ch...>]

Ivan,

(Bringing this discussion on-list so all can read).

Ivan Latysh wrote:
> Modularization is a good idea, but in case you are thinking to bring
> struts on board, pleas don't, servlet framework is sufficient enough fo=
r
> the project.

No, no. I was just using their architecture as something to look at and
emulate. We certainly wouldn't be incorporating any of their code or
using struts as a support library or anything like that.

> Wish-list:
> Support HttpRequest not only HttpServletRequest, so SF can be used with=

> WebDAV.

Do you mean that you want us to support ServletRequest and not just
HttpServletRequest? That might be a problem with the current
architecture, since we use the HttpSession (needs http heh heh heh) to
store the Principal object. WebDAV should always go over HTTP, though,
so I'm not sure why securityfilter + BASIC auth wouldn't work for WebDAV.=


Can you help me understand what we're missing?

Thanks,
-chris

Re: [securityfilter-devel] Securityfilter Improvements

[Christopher S. <ch...@ch...>]

Torgeir,

Torgeir Veimo wrote:
> On 5 Nov 2007, at 17:12, Christopher Schultz wrote:
>=20
>> General cleanup and updates:
>>
>> * Implement user-data-constraint (really transport-guarantee)
>=20
> This would allow automatic redirection to https for login pages? We=20
> would really like to have that feature.

Exactly. Both the servlet spec and the deployment descriptor comments
contain commentary similar to this:

"In most cases, the presence of the INTEGRAL or
CONFIDENTIAL flag will indicate that the use of SSL is required."

The only problem is that we'll have to allow for additional
configuration to specify what happens when the HTTP -> HTTPS switch is
made. For instance, Tomcat has Connectors that contain the configuration
for switching to HTTPS ("redirectPort", I think). We would need to add
that type of configuration to securityfilter-config.xml (which isn't hard=
).

>> Future Ideas:
>> * Eliminate use of jakarta-oro ; regexps are overkill for url-pattern
>> matching, and oro is nearly dead (right?)
>=20
> Any dependency removed would be nice. JDK regex is much better. Most =20
> projects are 1.4 or better these days.

Well, that might need to be a requirement of the new system. Then again,
the minimal url-pattern matching requirements do no need full regular
expression capabilities. Basically, you can use String.startsWith and
String.endsWith to handle everything, and I think that will improve
performance as well as remove a library dependency.

>> * Add support for CLIENT-CERT authentication
>=20
> Sounds tricky..

It's actually not that big of a deal, I think. If we continue to follow
the model of supporting Tomcat Realms right out of the box, I think we
can get away with adding a method to the SecurityRealmInterface that is
intended to call this method in Tomcat's realm:

    public Principal authenticate(X509Certificate certs[]);

It "should" be as simple as taking the cert list from the request and
passing it off to this method.

Thanks for the comments,
-chris

Re: [securityfilter-devel] Cleaning up old bugs

[Christopher S. <ch...@ch...>]

Torgeir,

Torgeir Veimo wrote:
> One enhancement I've used locally, is to check for 401 codes after the =
=20
> filter has run. This is done using a response wrapper in addition to =20
> the request wrapper, and some extra logic in the SecurityFilter class.
>=20
> This allows us to have a subsystem return a 401, and security filter =20
> automatically redirecting to the login screen. It makes it much easier =
=20
> to have dynamic permissions, since it's no longer declared statically  =

> in the security filter configuration file.
>=20
> This might be handy for someone else as well?

That sound interesting, but I don't think we'd want to include it in the
standard distribution. Securityfilter is intended to be used with
declarative security, so that's why I'm saying "no" to this request (at
least for the time being).

Perhaps with a more extensible (future) architecture, you'll be able to
easily add that capability without actually patching securityfilter
itself -- but instead subclass he filter and override some hooks or
something.

-chris

Re: [securityfilter-devel] Securityfilter Improvements

[Torgeir V. <to...@po...>]

On 5 Nov 2007, at 17:12, Christopher Schultz wrote:

> General cleanup and updates:
>
> * Implement user-data-constraint (really transport-guarantee)

This would allow automatic redirection to https for login pages? We  
would really like to have that feature.

> New features:
> * Implement optional per-login "tie login to this IP" capability

> Future Ideas:
> * Eliminate use of jakarta-oro ; regexps are overkill for url-pattern
> matching, and oro is nearly dead (right?)

Any dependency removed would be nice. JDK regex is much better. Most  
projects are 1.4 or better these days.

> * Add support for CLIENT-CERT authentication


Sounds tricky..

-- 
Torgeir Veimo
to...@po...