You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@tapestry.apache.org by Stephan Windmüller <st...@tu-dortmund.de> on 2010/11/09 11:17:19 UTC

Which security module to choose?

Hi!

We are currently using the integrated authentication of JBoss/Tomcat.
Secured pages are defined in the web.xml and the application server
redirects to the requested page after successful login. Users and
passwords are stored in an LDAP server. In future it would be nice to
extend this with OpenID.

The problem is: While the login page is shown, I do not have any access
to the activation context of the requested page. It would be nice to
know it in order to change the layout of the login page.

So I read some articles on this mailing list, deployed sample
implementations like spring-security and studied blog posts. This all
shed some light on the whole topic, but I am unsure which approach is
the best for us. In general I prefer some tested module to a self-made
solution. Spring security seems promising but may be overkill for our
use case. And would it fix my above issue?

I know this topic comes up regularly on this list but it would be nice
if someone could share his experience on this matter.

Regards
 Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: tynamo tapestry-security help

Posted by Kalle Korhonen <ka...@gmail.com>.

Thanks Everton! With a high certainty, that's the root cause. Perhaps
I'll just document this for now, wonder if T5.1.0.8 release will see
the light of the day at some point.

Kalle


On Wed, Nov 17, 2010 at 8:32 AM, Everton Agner <to...@gmail.com> wrote:
> You might be facing the TAP5-1018 Bug i've reported...
> https://issues.apache.org/jira/browse/TAP5-1018
>
> _______________________
> Everton Agner Ramos
>
>
> 2010/11/17 Kalle Korhonen <ka...@gmail.com>
>
>> Wonder if Start is handled differently than Index - if you can, please
>> check and open (Tynamo) issue accordingly.
>>
>> Kalle
>>
>>
>> On Wed, Nov 17, 2010 at 1:44 AM, Paul Stanton <pa...@mapshed.com.au> wrote:
>> > Hi Kalle,
>> >
>> > I've just tried t-s 0.2.1 and the
>> > org.apache.shiro.authz.annotation.RequiresAuthentication annotation.
>> >
>> > package zzz.pages;
>> >
>> > @RequiresAuthentication
>> > public class Start
>> > {}
>> >
>> > The same problem occurs.
>> > http://host/app/start - correctly directs to the login page
>> > http://host/app/ - incorrectly displays the page content
>> >
>> > regards, paul.
>> >
>> >
>> > On 16/11/2010 11:50 AM, Kalle Korhonen wrote:
>> >>
>> >> Move to tapestry-security 0.2.1 and use the Shiro
>> >> @RequiresAuthentication annotation instead. The *All annotations were
>> >> removed since I implemented them in Shiro directly (one of the
>> >> benefits of being a committer in both). We do have a couple of tests
>> >> for the case and those are passing. There's a possibility that it was
>> >> an issue with Shiro 1.0.0-incubating release.
>> >>
>> >> Kalle
>> >>
>> >>
>> >> On Sat, Nov 13, 2010 at 2:28 PM, Paul Stanton<pa...@mapshed.com.au>
>>  wrote:
>> >>>
>> >>> Also,
>> >>>
>> >>> I've marked my 'Start' page as @RequiresAuthenticationAll, and it
>> >>> correctly
>> >>> forwards to the login page when not already authenticated if the url is
>> >>>
>> >>> http://host/app/start
>> >>>
>> >>> however it displays the page's content if the url is
>> >>>
>> >>> http://host/app/
>> >>>
>> >>> This appears to be a bug IMO, is there a way to work around this or
>> >>> should I
>> >>> log an issue?
>> >>>
>> >>> p.
>> >>>
>> >>> On 12/11/2010 10:50 PM, Paul Stanton wrote:
>> >>>>
>> >>>> Kalle,
>> >>>>
>> >>>> Leaving that one behind...
>> >>>>
>> >>>> Where can I find the documentation regarding the various tapestry
>> >>>> components and pages provided by tapestry-security?
>> >>>>
>> >>>> The Javadoc only contains explainations for 5/11 of the components:
>> >>>>
>> >>>> http://tynamo.org/constant/tapestry-security/apidocs/index.html
>> >>>>
>> >>>> Also, is there a SVN i can download the source code from?
>> >>>>
>> >>>> regards, Paul.
>> >>>>
>> >>>> On 12/11/2010 10:56 AM, Kalle Korhonen wrote:
>> >>>>>
>> >>>>> On Thu, Nov 11, 2010 at 2:25 PM, Paul Stanton<pa...@mapshed.com.au>
>> >>>>>  wrote:
>> >>>>>>
>> >>>>>> Interesting. You can see the need for the behaviour but not the need
>> >>>>>> to
>> >>>>>> expose/implement it cleanly via the API.
>> >>>>>
>> >>>>> No, that's the wrong conclusion. Subscribe to the shiro dev list, we
>> >>>>> recently had extensive discussion on this but in the meantime I'm
>> >>>>> saying that you should do and I have done whatever I needed for my
>> >>>>> current needs.
>> >>>>>
>> >>>>> Kalle
>> >>>>>
>> >>>>>
>> >>>>>> For mine, I don't see why
>> >>>>>> 'HashedCredentialsMatcher.hashProvidedCredentials'
>> >>>>>> and 'getCredentials' are  protected, this makes it impossible to
>> >>>>>> expose
>> >>>>>> the
>> >>>>>> hashing functionality without subclassing, which means it is less
>> >>>>>> trivial to
>> >>>>>> change hash provider - the parent class of your custom HCM needs to
>> >>>>>> change.
>> >>>>>>
>> >>>>>> So I'll implement it like so:
>> >>>>>>
>> >>>>>> 1. Subclass chosen implementation of HashedCredentialsMatcher and
>> add
>> >>>>>> 'getHashedCredentials' to expose 'getCredentials'
>> >>>>>>
>> >>>>>> public class AppCredentialsMatcher extends Md5CredentialsMatcher //
>> >>>>>> for
>> >>>>>> example
>> >>>>>> {
>> >>>>>>    public Object getHashedCredentials(AuthenticationToken token)
>> >>>>>>    {
>> >>>>>>        return getCredentials(token);
>> >>>>>>    }
>> >>>>>> }
>> >>>>>>
>> >>>>>> 2. add 'getHashedCredentials' to my Realm:
>> >>>>>>
>> >>>>>>    public String getHashedCredentials(String username, String
>> >>>>>> password)
>> >>>>>>    {
>> >>>>>>        UsernamePasswordToken token = new
>> >>>>>> UsernamePasswordToken(username,
>> >>>>>> password);
>> >>>>>>        return String.valueOf(((AppCredentialsMatcher)
>> >>>>>> getCredentialsMatcher()).getHashedCredentials(token));
>> >>>>>>    }
>> >>>>>>
>> >>>>>> Maybe something like this could be built into the API?
>> >>>>>>
>> >>>>>> Regards, paul.
>> >>>>>>
>> >>>>>>
>> >>>>>> On 12/11/2010 3:30 AM, Kalle Korhonen wrote:
>> >>>>>>>
>> >>>>>>> Hmm.. if you use username as the salt, you already have stored the
>> >>>>>>> salt. For my own custom and application-specifc CredentialsMatcher
>> >>>>>>> implementations, I'm not too purist about these things: sometimes
>> >>>>>>> I've
>> >>>>>>> done it by just adding a static encode operation as part of the
>> >>>>>>> CredentialsMatcher, e.g.:
>> >>>>>>>        public static String encode(String password, int saltWidth,
>> >>>>>>> int
>> >>>>>>> hashIterations) {...}
>> >>>>>>>
>> >>>>>>> Kalle
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Thu, Nov 11, 2010 at 2:06 AM, Paul Stanton<pa...@mapshed.com.au>
>> >>>>>>>  wrote:
>> >>>>>>>>
>> >>>>>>>> Kalle,
>> >>>>>>>>
>> >>>>>>>> I think you misunderstood my question. I don't have a problem with
>> >>>>>>>> using
>> >>>>>>>> the
>> >>>>>>>> username as the salt, the salt has to be stored parallel to the
>> user
>> >>>>>>>> entity
>> >>>>>>>> somewhere anyway.
>> >>>>>>>>
>> >>>>>>>> I would like to know how to get access to the CredentialsMatcher
>> and
>> >>>>>>>> have
>> >>>>>>>> it
>> >>>>>>>> generate the hashed password for me NOT when authenticating but at
>> >>>>>>>> the
>> >>>>>>>> time
>> >>>>>>>> the user registers.
>> >>>>>>>>
>> >>>>>>>> In my opinion, the encoding scheme should be configured once, and
>> >>>>>>>> the
>> >>>>>>>> CredentialsMatcher seems like the obvious place so I would like to
>> >>>>>>>> use
>> >>>>>>>> it
>> >>>>>>>> whenever I need to generate the hashed version of the password.
>> >>>>>>>>
>> >>>>>>>> I'm thinking the only way to achieve this is to extend one of the
>> >>>>>>>> implementations of HashedCredentialsMatcher and expose a method
>> >>>>>>>> which
>> >>>>>>>> calls
>> >>>>>>>> 'hashProvidedCredentials', and then add another method on the
>> Realm
>> >>>>>>>> to
>> >>>>>>>> in
>> >>>>>>>> turn expose this feature.
>> >>>>>>>>
>> >>>>>>>> This seems like a lot of effort and reduces the flexibility of the
>> >>>>>>>> architecture. For something that must be a common need and
>> therefore
>> >>>>>>>> should
>> >>>>>>>> be exposed by the API, so i'm wondering if I've missed some
>> crucial
>> >>>>>>>> feature.
>> >>>>>>>>
>> >>>>>>>> Regards, paul.
>> >>>>>>>>
>> >>>>>>>> On 11/11/2010 5:04 PM, Kalle Korhonen wrote:
>> >>>>>>>>>
>> >>>>>>>>> On Wed, Nov 10, 2010 at 8:44 PM, Paul Stanton<
>> paul@mapshed.com.au>
>> >>>>>>>>>  wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Firstly, I'd like to use a salted hash to match credentials...
>> the
>> >>>>>>>>>> booking
>> >>>>>>>>>> example application does not do this and the documentation (for
>> >>>>>>>>>> shiro)
>> >>>>>>>>>> doesn't quite show the complete picture.
>> >>>>>>>>>
>> >>>>>>>>> Yeah I bet you are right on that. That should just work in my
>> >>>>>>>>> opinion
>> >>>>>>>>> without end user having to do any extra work. But you are in luck
>> >>>>>>>>> with
>> >>>>>>>>> that, kind of. 1.1.0 Shiro just added "built-in" support for
>> >>>>>>>>> per-user-salt. tapestry-security 0.3.0-SNAPSHOT integrates with
>> >>>>>>>>> 1.1.0
>> >>>>>>>>> Shiro and I'm going to cut the release pretty soon. See
>> >>>>>>>>> http://www.mail-archive.com/dev@shiro.apache.org/msg00107.htmland
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> http://svn.apache.org/repos/asf/shiro/trunk/core/src/test/java/org/apache/shiro/authc/credential/HashedCredentialsMatcherTest.java
>> >>>>>>>>> for ideas).
>> >>>>>>>>>
>> >>>>>>>>>> How can I get a handle to an instance of my CredentialsMatcher
>> and
>> >>>>>>>>>> then
>> >>>>>>>>>> expose the method of hashing? should I make it a service too? I
>> >>>>>>>>>> want
>> >>>>>>>>>> to
>> >>>>>>>>>> get
>> >>>>>>>>>> a handle to it in 2 places:
>> >>>>>>>>>> 1. at signup so i can persist the hashed password using the
>> >>>>>>>>>> identical
>> >>>>>>>>>> hashing mechanism
>> >>>>>>>>>> 2. in a database upgrade step so i can convert clear-text
>> >>>>>>>>>> passwords
>> >>>>>>>>>> into
>> >>>>>>>>>> the
>> >>>>>>>>>> hashed version
>> >>>>>>>>>
>> >>>>>>>>> I think you should handle all of this as part of your realm
>> >>>>>>>>> implementation with a custom AccountInfo. Not difficult to
>> >>>>>>>>> implement
>> >>>>>>>>> but some amount of API learning to do. I've been fancying myself
>> >>>>>>>>> with
>> >>>>>>>>> the idea of creating a tapestry-security-hibernate module with
>> >>>>>>>>> prefabricated (JPA) entitities because it's just pointless to do
>> >>>>>>>>> the
>> >>>>>>>>> same for every little webapp separately.
>> >>>>>>>>>
>> >>>>>>>>>> Why and how should I implement
>> >>>>>>>>>> AuthorizingRealm.doGetAuthorizationInfo(PrincipalCollection
>> >>>>>>>>>> principals)
>> >>>>>>>>>> ?
>> >>>>>>>>>> When would it be called in my basic application?
>> >>>>>>>>>
>> >>>>>>>>> It'll be called right after doGetAuthentication() assuming it
>> >>>>>>>>> succeeds
>> >>>>>>>>> if your realm promises to authorize users as well. A simple
>> example
>> >>>>>>>>> is
>> >>>>>>>>> that you could have a realm just to authenticate users against
>> >>>>>>>>> Facebook, Google etc. while another realm would be responsible
>> for
>> >>>>>>>>> *authorizing* users using the permission information (roles etc)
>> >>>>>>>>> stored in the local database. Often for a simpler webapp, you
>> have
>> >>>>>>>>> just a single realm which does both authentication and
>> >>>>>>>>> authorization.
>> >>>>>>>>>
>> >>>>>>>>> Kalle
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> On 11/11/2010 2:29 AM, Kalle Korhonen wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>> Ah you are looking for documentation on Shiro. Maybe I can
>> place
>> >>>>>>>>>>> the
>> >>>>>>>>>>> links to it more prominently on tapestry-security page, but see
>> >>>>>>>>>>> http://shiro.apache.org/core.html (there's more but for now
>> >>>>>>>>>>> Subject
>> >>>>>>>>>>> and Realms are the most relevant to you). If you want examples,
>> >>>>>>>>>>> Christophe's hotel booking demo with Tynamo
>> >>>>>>>>>>>
>> >>>>>>>>>>> (
>> https://github.com/ccordenier/tapestry5-hotel-booking/tree/tynamo)
>> >>>>>>>>>>> is
>> >>>>>>>>>>> very nice.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Kalle
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>
>> >>>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>
>> >>>>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: tynamo tapestry-security help

Posted by Everton Agner <to...@gmail.com>.

Btw, as a Workaround, you can make a ComponentRequestFilter that redirects
to the Start page when the url root path ("/yourapp/") is requested. That
would make it work.

_______________________
Everton Agner Ramos


2010/11/17 Everton Agner <to...@gmail.com>

> You might be facing the TAP5-1018 Bug i've reported...
> https://issues.apache.org/jira/browse/TAP5-1018
>
> _______________________
> Everton Agner Ramos
>
>
> 2010/11/17 Kalle Korhonen <ka...@gmail.com>
>
> Wonder if Start is handled differently than Index - if you can, please
>> check and open (Tynamo) issue accordingly.
>>
>> Kalle
>>
>>
>> On Wed, Nov 17, 2010 at 1:44 AM, Paul Stanton <pa...@mapshed.com.au>
>> wrote:
>> > Hi Kalle,
>> >
>> > I've just tried t-s 0.2.1 and the
>> > org.apache.shiro.authz.annotation.RequiresAuthentication annotation.
>> >
>> > package zzz.pages;
>> >
>> > @RequiresAuthentication
>> > public class Start
>> > {}
>> >
>> > The same problem occurs.
>> > http://host/app/start - correctly directs to the login page
>> > http://host/app/ - incorrectly displays the page content
>> >
>> > regards, paul.
>> >
>> >
>> > On 16/11/2010 11:50 AM, Kalle Korhonen wrote:
>> >>
>> >> Move to tapestry-security 0.2.1 and use the Shiro
>> >> @RequiresAuthentication annotation instead. The *All annotations were
>> >> removed since I implemented them in Shiro directly (one of the
>> >> benefits of being a committer in both). We do have a couple of tests
>> >> for the case and those are passing. There's a possibility that it was
>> >> an issue with Shiro 1.0.0-incubating release.
>> >>
>> >> Kalle
>> >>
>> >>
>> >> On Sat, Nov 13, 2010 at 2:28 PM, Paul Stanton<pa...@mapshed.com.au>
>>  wrote:
>> >>>
>> >>> Also,
>> >>>
>> >>> I've marked my 'Start' page as @RequiresAuthenticationAll, and it
>> >>> correctly
>> >>> forwards to the login page when not already authenticated if the url
>> is
>> >>>
>> >>> http://host/app/start
>> >>>
>> >>> however it displays the page's content if the url is
>> >>>
>> >>> http://host/app/
>> >>>
>> >>> This appears to be a bug IMO, is there a way to work around this or
>> >>> should I
>> >>> log an issue?
>> >>>
>> >>> p.
>> >>>
>> >>> On 12/11/2010 10:50 PM, Paul Stanton wrote:
>> >>>>
>> >>>> Kalle,
>> >>>>
>> >>>> Leaving that one behind...
>> >>>>
>> >>>> Where can I find the documentation regarding the various tapestry
>> >>>> components and pages provided by tapestry-security?
>> >>>>
>> >>>> The Javadoc only contains explainations for 5/11 of the components:
>> >>>>
>> >>>> http://tynamo.org/constant/tapestry-security/apidocs/index.html
>> >>>>
>> >>>> Also, is there a SVN i can download the source code from?
>> >>>>
>> >>>> regards, Paul.
>> >>>>
>> >>>> On 12/11/2010 10:56 AM, Kalle Korhonen wrote:
>> >>>>>
>> >>>>> On Thu, Nov 11, 2010 at 2:25 PM, Paul Stanton<pa...@mapshed.com.au>
>> >>>>>  wrote:
>> >>>>>>
>> >>>>>> Interesting. You can see the need for the behaviour but not the
>> need
>> >>>>>> to
>> >>>>>> expose/implement it cleanly via the API.
>> >>>>>
>> >>>>> No, that's the wrong conclusion. Subscribe to the shiro dev list, we
>> >>>>> recently had extensive discussion on this but in the meantime I'm
>> >>>>> saying that you should do and I have done whatever I needed for my
>> >>>>> current needs.
>> >>>>>
>> >>>>> Kalle
>> >>>>>
>> >>>>>
>> >>>>>> For mine, I don't see why
>> >>>>>> 'HashedCredentialsMatcher.hashProvidedCredentials'
>> >>>>>> and 'getCredentials' are  protected, this makes it impossible to
>> >>>>>> expose
>> >>>>>> the
>> >>>>>> hashing functionality without subclassing, which means it is less
>> >>>>>> trivial to
>> >>>>>> change hash provider - the parent class of your custom HCM needs to
>> >>>>>> change.
>> >>>>>>
>> >>>>>> So I'll implement it like so:
>> >>>>>>
>> >>>>>> 1. Subclass chosen implementation of HashedCredentialsMatcher and
>> add
>> >>>>>> 'getHashedCredentials' to expose 'getCredentials'
>> >>>>>>
>> >>>>>> public class AppCredentialsMatcher extends Md5CredentialsMatcher //
>> >>>>>> for
>> >>>>>> example
>> >>>>>> {
>> >>>>>>    public Object getHashedCredentials(AuthenticationToken token)
>> >>>>>>    {
>> >>>>>>        return getCredentials(token);
>> >>>>>>    }
>> >>>>>> }
>> >>>>>>
>> >>>>>> 2. add 'getHashedCredentials' to my Realm:
>> >>>>>>
>> >>>>>>    public String getHashedCredentials(String username, String
>> >>>>>> password)
>> >>>>>>    {
>> >>>>>>        UsernamePasswordToken token = new
>> >>>>>> UsernamePasswordToken(username,
>> >>>>>> password);
>> >>>>>>        return String.valueOf(((AppCredentialsMatcher)
>> >>>>>> getCredentialsMatcher()).getHashedCredentials(token));
>> >>>>>>    }
>> >>>>>>
>> >>>>>> Maybe something like this could be built into the API?
>> >>>>>>
>> >>>>>> Regards, paul.
>> >>>>>>
>> >>>>>>
>> >>>>>> On 12/11/2010 3:30 AM, Kalle Korhonen wrote:
>> >>>>>>>
>> >>>>>>> Hmm.. if you use username as the salt, you already have stored the
>> >>>>>>> salt. For my own custom and application-specifc CredentialsMatcher
>> >>>>>>> implementations, I'm not too purist about these things: sometimes
>> >>>>>>> I've
>> >>>>>>> done it by just adding a static encode operation as part of the
>> >>>>>>> CredentialsMatcher, e.g.:
>> >>>>>>>        public static String encode(String password, int saltWidth,
>> >>>>>>> int
>> >>>>>>> hashIterations) {...}
>> >>>>>>>
>> >>>>>>> Kalle
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Thu, Nov 11, 2010 at 2:06 AM, Paul Stanton<paul@mapshed.com.au
>> >
>> >>>>>>>  wrote:
>> >>>>>>>>
>> >>>>>>>> Kalle,
>> >>>>>>>>
>> >>>>>>>> I think you misunderstood my question. I don't have a problem
>> with
>> >>>>>>>> using
>> >>>>>>>> the
>> >>>>>>>> username as the salt, the salt has to be stored parallel to the
>> user
>> >>>>>>>> entity
>> >>>>>>>> somewhere anyway.
>> >>>>>>>>
>> >>>>>>>> I would like to know how to get access to the CredentialsMatcher
>> and
>> >>>>>>>> have
>> >>>>>>>> it
>> >>>>>>>> generate the hashed password for me NOT when authenticating but
>> at
>> >>>>>>>> the
>> >>>>>>>> time
>> >>>>>>>> the user registers.
>> >>>>>>>>
>> >>>>>>>> In my opinion, the encoding scheme should be configured once, and
>> >>>>>>>> the
>> >>>>>>>> CredentialsMatcher seems like the obvious place so I would like
>> to
>> >>>>>>>> use
>> >>>>>>>> it
>> >>>>>>>> whenever I need to generate the hashed version of the password.
>> >>>>>>>>
>> >>>>>>>> I'm thinking the only way to achieve this is to extend one of the
>> >>>>>>>> implementations of HashedCredentialsMatcher and expose a method
>> >>>>>>>> which
>> >>>>>>>> calls
>> >>>>>>>> 'hashProvidedCredentials', and then add another method on the
>> Realm
>> >>>>>>>> to
>> >>>>>>>> in
>> >>>>>>>> turn expose this feature.
>> >>>>>>>>
>> >>>>>>>> This seems like a lot of effort and reduces the flexibility of
>> the
>> >>>>>>>> architecture. For something that must be a common need and
>> therefore
>> >>>>>>>> should
>> >>>>>>>> be exposed by the API, so i'm wondering if I've missed some
>> crucial
>> >>>>>>>> feature.
>> >>>>>>>>
>> >>>>>>>> Regards, paul.
>> >>>>>>>>
>> >>>>>>>> On 11/11/2010 5:04 PM, Kalle Korhonen wrote:
>> >>>>>>>>>
>> >>>>>>>>> On Wed, Nov 10, 2010 at 8:44 PM, Paul Stanton<
>> paul@mapshed.com.au>
>> >>>>>>>>>  wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Firstly, I'd like to use a salted hash to match credentials...
>> the
>> >>>>>>>>>> booking
>> >>>>>>>>>> example application does not do this and the documentation (for
>> >>>>>>>>>> shiro)
>> >>>>>>>>>> doesn't quite show the complete picture.
>> >>>>>>>>>
>> >>>>>>>>> Yeah I bet you are right on that. That should just work in my
>> >>>>>>>>> opinion
>> >>>>>>>>> without end user having to do any extra work. But you are in
>> luck
>> >>>>>>>>> with
>> >>>>>>>>> that, kind of. 1.1.0 Shiro just added "built-in" support for
>> >>>>>>>>> per-user-salt. tapestry-security 0.3.0-SNAPSHOT integrates with
>> >>>>>>>>> 1.1.0
>> >>>>>>>>> Shiro and I'm going to cut the release pretty soon. See
>> >>>>>>>>> http://www.mail-archive.com/dev@shiro.apache.org/msg00107.htmland
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> http://svn.apache.org/repos/asf/shiro/trunk/core/src/test/java/org/apache/shiro/authc/credential/HashedCredentialsMatcherTest.java
>> >>>>>>>>> for ideas).
>> >>>>>>>>>
>> >>>>>>>>>> How can I get a handle to an instance of my CredentialsMatcher
>> and
>> >>>>>>>>>> then
>> >>>>>>>>>> expose the method of hashing? should I make it a service too? I
>> >>>>>>>>>> want
>> >>>>>>>>>> to
>> >>>>>>>>>> get
>> >>>>>>>>>> a handle to it in 2 places:
>> >>>>>>>>>> 1. at signup so i can persist the hashed password using the
>> >>>>>>>>>> identical
>> >>>>>>>>>> hashing mechanism
>> >>>>>>>>>> 2. in a database upgrade step so i can convert clear-text
>> >>>>>>>>>> passwords
>> >>>>>>>>>> into
>> >>>>>>>>>> the
>> >>>>>>>>>> hashed version
>> >>>>>>>>>
>> >>>>>>>>> I think you should handle all of this as part of your realm
>> >>>>>>>>> implementation with a custom AccountInfo. Not difficult to
>> >>>>>>>>> implement
>> >>>>>>>>> but some amount of API learning to do. I've been fancying myself
>> >>>>>>>>> with
>> >>>>>>>>> the idea of creating a tapestry-security-hibernate module with
>> >>>>>>>>> prefabricated (JPA) entitities because it's just pointless to do
>> >>>>>>>>> the
>> >>>>>>>>> same for every little webapp separately.
>> >>>>>>>>>
>> >>>>>>>>>> Why and how should I implement
>> >>>>>>>>>> AuthorizingRealm.doGetAuthorizationInfo(PrincipalCollection
>> >>>>>>>>>> principals)
>> >>>>>>>>>> ?
>> >>>>>>>>>> When would it be called in my basic application?
>> >>>>>>>>>
>> >>>>>>>>> It'll be called right after doGetAuthentication() assuming it
>> >>>>>>>>> succeeds
>> >>>>>>>>> if your realm promises to authorize users as well. A simple
>> example
>> >>>>>>>>> is
>> >>>>>>>>> that you could have a realm just to authenticate users against
>> >>>>>>>>> Facebook, Google etc. while another realm would be responsible
>> for
>> >>>>>>>>> *authorizing* users using the permission information (roles etc)
>> >>>>>>>>> stored in the local database. Often for a simpler webapp, you
>> have
>> >>>>>>>>> just a single realm which does both authentication and
>> >>>>>>>>> authorization.
>> >>>>>>>>>
>> >>>>>>>>> Kalle
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> On 11/11/2010 2:29 AM, Kalle Korhonen wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>> Ah you are looking for documentation on Shiro. Maybe I can
>> place
>> >>>>>>>>>>> the
>> >>>>>>>>>>> links to it more prominently on tapestry-security page, but
>> see
>> >>>>>>>>>>> http://shiro.apache.org/core.html (there's more but for now
>> >>>>>>>>>>> Subject
>> >>>>>>>>>>> and Realms are the most relevant to you). If you want
>> examples,
>> >>>>>>>>>>> Christophe's hotel booking demo with Tynamo
>> >>>>>>>>>>>
>> >>>>>>>>>>> (
>> https://github.com/ccordenier/tapestry5-hotel-booking/tree/tynamo)
>> >>>>>>>>>>> is
>> >>>>>>>>>>> very nice.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Kalle
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>>>>>>> For additional commands, e-mail:
>> users-help@tapestry.apache.org
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>
>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>
>> >>>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>
>> >>>>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>

Re: tynamo tapestry-security help

Posted by Everton Agner <to...@gmail.com>.

You might be facing the TAP5-1018 Bug i've reported...
https://issues.apache.org/jira/browse/TAP5-1018

_______________________
Everton Agner Ramos


2010/11/17 Kalle Korhonen <ka...@gmail.com>

> Wonder if Start is handled differently than Index - if you can, please
> check and open (Tynamo) issue accordingly.
>
> Kalle
>
>
> On Wed, Nov 17, 2010 at 1:44 AM, Paul Stanton <pa...@mapshed.com.au> wrote:
> > Hi Kalle,
> >
> > I've just tried t-s 0.2.1 and the
> > org.apache.shiro.authz.annotation.RequiresAuthentication annotation.
> >
> > package zzz.pages;
> >
> > @RequiresAuthentication
> > public class Start
> > {}
> >
> > The same problem occurs.
> > http://host/app/start - correctly directs to the login page
> > http://host/app/ - incorrectly displays the page content
> >
> > regards, paul.
> >
> >
> > On 16/11/2010 11:50 AM, Kalle Korhonen wrote:
> >>
> >> Move to tapestry-security 0.2.1 and use the Shiro
> >> @RequiresAuthentication annotation instead. The *All annotations were
> >> removed since I implemented them in Shiro directly (one of the
> >> benefits of being a committer in both). We do have a couple of tests
> >> for the case and those are passing. There's a possibility that it was
> >> an issue with Shiro 1.0.0-incubating release.
> >>
> >> Kalle
> >>
> >>
> >> On Sat, Nov 13, 2010 at 2:28 PM, Paul Stanton<pa...@mapshed.com.au>
>  wrote:
> >>>
> >>> Also,
> >>>
> >>> I've marked my 'Start' page as @RequiresAuthenticationAll, and it
> >>> correctly
> >>> forwards to the login page when not already authenticated if the url is
> >>>
> >>> http://host/app/start
> >>>
> >>> however it displays the page's content if the url is
> >>>
> >>> http://host/app/
> >>>
> >>> This appears to be a bug IMO, is there a way to work around this or
> >>> should I
> >>> log an issue?
> >>>
> >>> p.
> >>>
> >>> On 12/11/2010 10:50 PM, Paul Stanton wrote:
> >>>>
> >>>> Kalle,
> >>>>
> >>>> Leaving that one behind...
> >>>>
> >>>> Where can I find the documentation regarding the various tapestry
> >>>> components and pages provided by tapestry-security?
> >>>>
> >>>> The Javadoc only contains explainations for 5/11 of the components:
> >>>>
> >>>> http://tynamo.org/constant/tapestry-security/apidocs/index.html
> >>>>
> >>>> Also, is there a SVN i can download the source code from?
> >>>>
> >>>> regards, Paul.
> >>>>
> >>>> On 12/11/2010 10:56 AM, Kalle Korhonen wrote:
> >>>>>
> >>>>> On Thu, Nov 11, 2010 at 2:25 PM, Paul Stanton<pa...@mapshed.com.au>
> >>>>>  wrote:
> >>>>>>
> >>>>>> Interesting. You can see the need for the behaviour but not the need
> >>>>>> to
> >>>>>> expose/implement it cleanly via the API.
> >>>>>
> >>>>> No, that's the wrong conclusion. Subscribe to the shiro dev list, we
> >>>>> recently had extensive discussion on this but in the meantime I'm
> >>>>> saying that you should do and I have done whatever I needed for my
> >>>>> current needs.
> >>>>>
> >>>>> Kalle
> >>>>>
> >>>>>
> >>>>>> For mine, I don't see why
> >>>>>> 'HashedCredentialsMatcher.hashProvidedCredentials'
> >>>>>> and 'getCredentials' are  protected, this makes it impossible to
> >>>>>> expose
> >>>>>> the
> >>>>>> hashing functionality without subclassing, which means it is less
> >>>>>> trivial to
> >>>>>> change hash provider - the parent class of your custom HCM needs to
> >>>>>> change.
> >>>>>>
> >>>>>> So I'll implement it like so:
> >>>>>>
> >>>>>> 1. Subclass chosen implementation of HashedCredentialsMatcher and
> add
> >>>>>> 'getHashedCredentials' to expose 'getCredentials'
> >>>>>>
> >>>>>> public class AppCredentialsMatcher extends Md5CredentialsMatcher //
> >>>>>> for
> >>>>>> example
> >>>>>> {
> >>>>>>    public Object getHashedCredentials(AuthenticationToken token)
> >>>>>>    {
> >>>>>>        return getCredentials(token);
> >>>>>>    }
> >>>>>> }
> >>>>>>
> >>>>>> 2. add 'getHashedCredentials' to my Realm:
> >>>>>>
> >>>>>>    public String getHashedCredentials(String username, String
> >>>>>> password)
> >>>>>>    {
> >>>>>>        UsernamePasswordToken token = new
> >>>>>> UsernamePasswordToken(username,
> >>>>>> password);
> >>>>>>        return String.valueOf(((AppCredentialsMatcher)
> >>>>>> getCredentialsMatcher()).getHashedCredentials(token));
> >>>>>>    }
> >>>>>>
> >>>>>> Maybe something like this could be built into the API?
> >>>>>>
> >>>>>> Regards, paul.
> >>>>>>
> >>>>>>
> >>>>>> On 12/11/2010 3:30 AM, Kalle Korhonen wrote:
> >>>>>>>
> >>>>>>> Hmm.. if you use username as the salt, you already have stored the
> >>>>>>> salt. For my own custom and application-specifc CredentialsMatcher
> >>>>>>> implementations, I'm not too purist about these things: sometimes
> >>>>>>> I've
> >>>>>>> done it by just adding a static encode operation as part of the
> >>>>>>> CredentialsMatcher, e.g.:
> >>>>>>>        public static String encode(String password, int saltWidth,
> >>>>>>> int
> >>>>>>> hashIterations) {...}
> >>>>>>>
> >>>>>>> Kalle
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Nov 11, 2010 at 2:06 AM, Paul Stanton<pa...@mapshed.com.au>
> >>>>>>>  wrote:
> >>>>>>>>
> >>>>>>>> Kalle,
> >>>>>>>>
> >>>>>>>> I think you misunderstood my question. I don't have a problem with
> >>>>>>>> using
> >>>>>>>> the
> >>>>>>>> username as the salt, the salt has to be stored parallel to the
> user
> >>>>>>>> entity
> >>>>>>>> somewhere anyway.
> >>>>>>>>
> >>>>>>>> I would like to know how to get access to the CredentialsMatcher
> and
> >>>>>>>> have
> >>>>>>>> it
> >>>>>>>> generate the hashed password for me NOT when authenticating but at
> >>>>>>>> the
> >>>>>>>> time
> >>>>>>>> the user registers.
> >>>>>>>>
> >>>>>>>> In my opinion, the encoding scheme should be configured once, and
> >>>>>>>> the
> >>>>>>>> CredentialsMatcher seems like the obvious place so I would like to
> >>>>>>>> use
> >>>>>>>> it
> >>>>>>>> whenever I need to generate the hashed version of the password.
> >>>>>>>>
> >>>>>>>> I'm thinking the only way to achieve this is to extend one of the
> >>>>>>>> implementations of HashedCredentialsMatcher and expose a method
> >>>>>>>> which
> >>>>>>>> calls
> >>>>>>>> 'hashProvidedCredentials', and then add another method on the
> Realm
> >>>>>>>> to
> >>>>>>>> in
> >>>>>>>> turn expose this feature.
> >>>>>>>>
> >>>>>>>> This seems like a lot of effort and reduces the flexibility of the
> >>>>>>>> architecture. For something that must be a common need and
> therefore
> >>>>>>>> should
> >>>>>>>> be exposed by the API, so i'm wondering if I've missed some
> crucial
> >>>>>>>> feature.
> >>>>>>>>
> >>>>>>>> Regards, paul.
> >>>>>>>>
> >>>>>>>> On 11/11/2010 5:04 PM, Kalle Korhonen wrote:
> >>>>>>>>>
> >>>>>>>>> On Wed, Nov 10, 2010 at 8:44 PM, Paul Stanton<
> paul@mapshed.com.au>
> >>>>>>>>>  wrote:
> >>>>>>>>>>
> >>>>>>>>>> Firstly, I'd like to use a salted hash to match credentials...
> the
> >>>>>>>>>> booking
> >>>>>>>>>> example application does not do this and the documentation (for
> >>>>>>>>>> shiro)
> >>>>>>>>>> doesn't quite show the complete picture.
> >>>>>>>>>
> >>>>>>>>> Yeah I bet you are right on that. That should just work in my
> >>>>>>>>> opinion
> >>>>>>>>> without end user having to do any extra work. But you are in luck
> >>>>>>>>> with
> >>>>>>>>> that, kind of. 1.1.0 Shiro just added "built-in" support for
> >>>>>>>>> per-user-salt. tapestry-security 0.3.0-SNAPSHOT integrates with
> >>>>>>>>> 1.1.0
> >>>>>>>>> Shiro and I'm going to cut the release pretty soon. See
> >>>>>>>>> http://www.mail-archive.com/dev@shiro.apache.org/msg00107.htmland
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> http://svn.apache.org/repos/asf/shiro/trunk/core/src/test/java/org/apache/shiro/authc/credential/HashedCredentialsMatcherTest.java
> >>>>>>>>> for ideas).
> >>>>>>>>>
> >>>>>>>>>> How can I get a handle to an instance of my CredentialsMatcher
> and
> >>>>>>>>>> then
> >>>>>>>>>> expose the method of hashing? should I make it a service too? I
> >>>>>>>>>> want
> >>>>>>>>>> to
> >>>>>>>>>> get
> >>>>>>>>>> a handle to it in 2 places:
> >>>>>>>>>> 1. at signup so i can persist the hashed password using the
> >>>>>>>>>> identical
> >>>>>>>>>> hashing mechanism
> >>>>>>>>>> 2. in a database upgrade step so i can convert clear-text
> >>>>>>>>>> passwords
> >>>>>>>>>> into
> >>>>>>>>>> the
> >>>>>>>>>> hashed version
> >>>>>>>>>
> >>>>>>>>> I think you should handle all of this as part of your realm
> >>>>>>>>> implementation with a custom AccountInfo. Not difficult to
> >>>>>>>>> implement
> >>>>>>>>> but some amount of API learning to do. I've been fancying myself
> >>>>>>>>> with
> >>>>>>>>> the idea of creating a tapestry-security-hibernate module with
> >>>>>>>>> prefabricated (JPA) entitities because it's just pointless to do
> >>>>>>>>> the
> >>>>>>>>> same for every little webapp separately.
> >>>>>>>>>
> >>>>>>>>>> Why and how should I implement
> >>>>>>>>>> AuthorizingRealm.doGetAuthorizationInfo(PrincipalCollection
> >>>>>>>>>> principals)
> >>>>>>>>>> ?
> >>>>>>>>>> When would it be called in my basic application?
> >>>>>>>>>
> >>>>>>>>> It'll be called right after doGetAuthentication() assuming it
> >>>>>>>>> succeeds
> >>>>>>>>> if your realm promises to authorize users as well. A simple
> example
> >>>>>>>>> is
> >>>>>>>>> that you could have a realm just to authenticate users against
> >>>>>>>>> Facebook, Google etc. while another realm would be responsible
> for
> >>>>>>>>> *authorizing* users using the permission information (roles etc)
> >>>>>>>>> stored in the local database. Often for a simpler webapp, you
> have
> >>>>>>>>> just a single realm which does both authentication and
> >>>>>>>>> authorization.
> >>>>>>>>>
> >>>>>>>>> Kalle
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On 11/11/2010 2:29 AM, Kalle Korhonen wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Ah you are looking for documentation on Shiro. Maybe I can
> place
> >>>>>>>>>>> the
> >>>>>>>>>>> links to it more prominently on tapestry-security page, but see
> >>>>>>>>>>> http://shiro.apache.org/core.html (there's more but for now
> >>>>>>>>>>> Subject
> >>>>>>>>>>> and Realms are the most relevant to you). If you want examples,
> >>>>>>>>>>> Christophe's hotel booking demo with Tynamo
> >>>>>>>>>>>
> >>>>>>>>>>> (
> https://github.com/ccordenier/tapestry5-hotel-booking/tree/tynamo)
> >>>>>>>>>>> is
> >>>>>>>>>>> very nice.
> >>>>>>>>>>>
> >>>>>>>>>>> Kalle
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>
> >>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>