You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by "David G." <da...@gmail.com> on 2012/04/03 16:04:37 UTC

Sling Auth Questions

Hi,

So i've been poking around the src for Sling's FormAuth handler to
understand how its built out and ran into something slightly alarming (I
could just not be following the code through properly though).

It seems that Sling Form Auth works like this:

1) User provides user/pass
2) User's user/pass are validated
3) User's autoinfo (password, secureTokenNum, etc.) are stored in the
Session(??)
4) User is issued a cookie wi the userId and secureTokenNum
5) User makes a request w the cookie
6) Sling validates the cookie (looking up secureTokenNum in the Session)
7) User gets the authInfo (password) from the Session and sends it to the
LoginModule

Is my understanding of this correct?

If so how does this solution scale across servers? Is there some
persistence mechanism im missing? Or are users being logged in using
something like trust credentials?

Thanks

Re: Sling Auth Questions

Posted by "David G." <da...@gmail.com>.
ah - so the AuthStorage flips between Cookies and Sessions for the
auth data storage -- that makes more sense.

I still dont see how this creates a "valid" authenticationInfo object:

    private AuthenticationInfo createAuthInfo(final String authData) {
        final String userId = getUserId(authData);
        if (userId == null) {
            return null;
        }

        final AuthenticationInfo info = new AuthenticationInfo(
            HttpServletRequest.FORM_AUTH, userId);
        info.put(attrCookieAuthData, authData);

        return info;
    }


Is this enough to create an authorizable authinfo object?

        info.put(attrCookieAuthData, authData);

attrCookieAuthData indicates the name of the cookie/request attribute,
and authdata looks like the contents of the cookie/session attr.

Is the decomposition and validation of the authData happening
someplace else (login module)?

The whole token in the JCR seems like it has its own pitfalls w
thinking about persistence/latency -- and even possible performance
implications. Using HMAC-SHA1/MD5 i can determine the validity of a
Cookie in memory (without having to hit the disk/io) -- and by pass
login module execution if I know the cookie is invalid.



On Tue, Apr 3, 2012 at 10:42 AM, David G. <da...@gmail.com> wrote:
>
> Correct - a RESTful platform should not depend on the transient state of a server (Session).
>
> Its possible its storing it in the JCR, thought the Sling code appears to be storing it int he Session.
>
> See the last few methods in and trace back up the call stack: http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/form/src/main/java/org/apache/sling/auth/form/impl/FormAuthenticationHandler.java
>
> It seems that the securetokennumber is used to help prevent cookie spoofing even after the cookie itself has expired (i think?)
>
> it seems like the the Password is getting stored somewhere unhashed (the session, certainly not the cookie) so the user can be authenticated w each request. I dont see the user of trusted-credentials anywhere, though there may be some other auth mechanism in play that im not aware of.
>
> Also, wouldnt persisting data to the JCR be asking for persistence lag? It seems very possible that the client (could be programmatic and hot human) could issue HTTP requests faster than the secure data could be persisted between all JCRs in the cluster (especially if the JCRs are distributed geographically). I've seen issues where redirects after user registration can result in errors because the user data hasnt been persisted to another JCR (in the same data center) on a simple redirect (used sticky sessions to solve this issue).
>
>
> On Tue, Apr 3, 2012 at 10:29 AM, Sarwar Bhuiyan <sa...@gmail.com> wrote:
>>
>> Are you talking about what happens when user requests are load balanced and
>> a request could potentially go to different servers?
>>
>> I'm not sure what the detail is for the form auth handler but could be the
>> secure token is temporary stored in the user's JCR node?
>>
>> Sarwar
>>
>> On Tue, Apr 3, 2012 at 3:04 PM, David G. <da...@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > So i've been poking around the src for Sling's FormAuth handler to
>> > understand how its built out and ran into something slightly alarming (I
>> > could just not be following the code through properly though).
>> >
>> > It seems that Sling Form Auth works like this:
>> >
>> > 1) User provides user/pass
>> > 2) User's user/pass are validated
>> > 3) User's autoinfo (password, secureTokenNum, etc.) are stored in the
>> > Session(??)
>> > 4) User is issued a cookie wi the userId and secureTokenNum
>> > 5) User makes a request w the cookie
>> > 6) Sling validates the cookie (looking up secureTokenNum in the Session)
>> > 7) User gets the authInfo (password) from the Session and sends it to the
>> > LoginModule
>> >
>> > Is my understanding of this correct?
>> >
>> > If so how does this solution scale across servers? Is there some
>> > persistence mechanism im missing? Or are users being logged in using
>> > something like trust credentials?
>> >
>> > Thanks
>> >
>
>

Re: Sling Auth Questions

Posted by "David G." <da...@gmail.com>.
Correct - a RESTful platform should not depend on the transient state of a
server (Session).

Its possible its storing it in the JCR, thought the Sling code appears to
be storing it int he Session.

See the last few methods in and trace back up the call stack:
http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/form/src/main/java/org/apache/sling/auth/form/impl/FormAuthenticationHandler.java

It seems that the securetokennumber is used to help prevent cookie spoofing
even after the cookie itself has expired (i think?)

it seems like the the Password is getting stored somewhere unhashed (the
session, certainly not the cookie) so the user can be authenticated w each
request. I dont see the user of trusted-credentials anywhere, though there
may be some other auth mechanism in play that im not aware of.

Also, wouldnt persisting data to the JCR be asking for persistence lag? It
seems very possible that the client (could be programmatic and hot human)
could issue HTTP requests faster than the secure data could be persisted
between all JCRs in the cluster (especially if the JCRs are distributed
geographically). I've seen issues where redirects after user registration
can result in errors because the user data hasnt been persisted to another
JCR (in the same data center) on a simple redirect (used sticky sessions to
solve this issue).


On Tue, Apr 3, 2012 at 10:29 AM, Sarwar Bhuiyan <sa...@gmail.com>wrote:

> Are you talking about what happens when user requests are load balanced and
> a request could potentially go to different servers?
>
> I'm not sure what the detail is for the form auth handler but could be the
> secure token is temporary stored in the user's JCR node?
>
> Sarwar
>
> On Tue, Apr 3, 2012 at 3:04 PM, David G. <da...@gmail.com> wrote:
>
> > Hi,
> >
> > So i've been poking around the src for Sling's FormAuth handler to
> > understand how its built out and ran into something slightly alarming (I
> > could just not be following the code through properly though).
> >
> > It seems that Sling Form Auth works like this:
> >
> > 1) User provides user/pass
> > 2) User's user/pass are validated
> > 3) User's autoinfo (password, secureTokenNum, etc.) are stored in the
> > Session(??)
> > 4) User is issued a cookie wi the userId and secureTokenNum
> > 5) User makes a request w the cookie
> > 6) Sling validates the cookie (looking up secureTokenNum in the Session)
> > 7) User gets the authInfo (password) from the Session and sends it to the
> > LoginModule
> >
> > Is my understanding of this correct?
> >
> > If so how does this solution scale across servers? Is there some
> > persistence mechanism im missing? Or are users being logged in using
> > something like trust credentials?
> >
> > Thanks
> >
>

Re: Sling Auth Questions

Posted by Sarwar Bhuiyan <sa...@gmail.com>.
Are you talking about what happens when user requests are load balanced and
a request could potentially go to different servers?

I'm not sure what the detail is for the form auth handler but could be the
secure token is temporary stored in the user's JCR node?

Sarwar

On Tue, Apr 3, 2012 at 3:04 PM, David G. <da...@gmail.com> wrote:

> Hi,
>
> So i've been poking around the src for Sling's FormAuth handler to
> understand how its built out and ran into something slightly alarming (I
> could just not be following the code through properly though).
>
> It seems that Sling Form Auth works like this:
>
> 1) User provides user/pass
> 2) User's user/pass are validated
> 3) User's autoinfo (password, secureTokenNum, etc.) are stored in the
> Session(??)
> 4) User is issued a cookie wi the userId and secureTokenNum
> 5) User makes a request w the cookie
> 6) Sling validates the cookie (looking up secureTokenNum in the Session)
> 7) User gets the authInfo (password) from the Session and sends it to the
> LoginModule
>
> Is my understanding of this correct?
>
> If so how does this solution scale across servers? Is there some
> persistence mechanism im missing? Or are users being logged in using
> something like trust credentials?
>
> Thanks
>