Good morning everybody, I'm not sure if this jira was filled correctly https://issues.jboss.org/browse/PLINK-84 Let me know.

Is picketlink-core being used for authentication? The default Identity implementation should already protect against this kind of thing: if (isLoggedIn()) { if (isAuthenticationRequestWithDifferentUserId()) { throw new UnexpectedCredentialException("active user: " + this.user.getId() + " provided credentials: " + this.loginCredential.getUserId()); } beanManager.fireEvent(new AlreadyLoggedInEvent()); return AuthenticationResult.SUCCESS; } On 30/01/13 06:58, Anil Saldhana wrote: > From what I understand from JIRA comments, the use case boils down to > use of additional credentials after a successful authentication. > > I am thinking maybe the authentication process should register the type > of credential last used and if subsequent login() calls happen on the > identity, then a change of credential (via the credential.setCredential) > should trigger an authentication process. > > Unless the credential type has changed, I am unsure why we need to > perform another authentication when the user has already authenticated > and the session is active. > > Thoughts/feedback? > > On 01/29/2013 08:28 AM, Bruno Oliveira wrote: >> Good morning everybody, I'm not sure if this jira was filled correctly https://issues.jboss.org/browse/PLINK-84 >> >> Let me know. >> >> >>

Shane, this is not a bug rather a feature request.

Aerogear has the following sequence: credential.setCredential(x); identity.login(); credential.setCredential(y); identity.login(); Aerogear wants PicketLink to reauthenticate during the second login() call. Currently it will not because the first login() established a User instance and subsequent login() calls will just bypass the auth process.

Can you confirm that it's actually logging in with the new credentials, or merely just returning a "successful" result while leaving the state of the currently logged in user unchanged? On 30/01/13 12:08, Douglas Campos wrote: > On Tue, Jan 29, 2013 at 05:19:23PM -0600, Anil Saldhana wrote: > > Shane, > > this is not a bug rather a feature request. > > > it's a bug > > Aerogear has the following sequence: > > > > credential.setCredential(x); > > identity.login(); > > credential.setCredential(y); > > identity.login(); > > > > Aerogear wants PicketLink to reauthenticate during the second login() > > call. Currently > > it will not because the first login() established a User instance and > > subsequent login() > > calls will just bypass the auth process. > > > If my API doesn't do the login process on the login() call, am I not > failing with the "least surprise principle"? If it doesn't do all the > login procedure when called, better rename it then: mayLogin(), > loginWithCaching() or anything like this. > > IMO, this is not only wrong, but I think it can be used as a potential > attack vector. > > -- qmx > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org) > https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org) https://lists.jboss.org/mailman/listinfo/security-dev

On Tue, Jan 29, 2013 at 05:19:23PM -0600, Anil Saldhana wrote: > Shane, > this is not a bug rather a feature request. it's a bug > Aerogear has the following sequence: > > credential.setCredential(x); > identity.login(); > credential.setCredential(y); > identity.login(); > > Aerogear wants PicketLink to reauthenticate during the second login() > call. Currently > it will not because the first login() established a User instance and > subsequent login() > calls will just bypass the auth process. If my API doesn't do the login process on the login() call, am I not failing with the "least surprise principle"? If it doesn't do all the login procedure when called, better rename it then: mayLogin(), loginWithCaching() or anything like this.

IMO, this is not only wrong, but I think it can be used as a potential attack vector.

-- qmx

So if I'm a bank where the user account is logged in, this user has just forgot to 'logout'. Another person using his computer can just bypass the login, because the session still exists?

Another scenario, I'm at the same network of John, running my whatever-sniffer, then is just a matter of grab the current session ID and login? Am I wrong? Because If understood correctly, after user login, even if I invoke this method for a second time, what really matters is the session ID.

I'm confused. -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Wednesday, January 30, 2013 at 1:17 PM, Anil Saldhana wrote: > >On 01/29/2013 08:08 PM, Douglas Campos wrote: >> > >On Tue, Jan 29, 2013 at 05:19:23PM -0600, Anil Saldhana wrote: >>> > > >Shane, >>> > > >this is not a bug rather a feature request. >> > > >> > > >> > >it's a bug >>> > > >Aerogear has the following sequence: >>> > > > >>> > > >credential.setCredential(x); >>> > > >identity.login(); >>> > > >credential.setCredential(y); >>> > > >identity.login(); >>> > > > >>> > > >Aerogear wants PicketLink to reauthenticate during the second login() >>> > > >call. Currently >>> > > >it will not because the first login() established a User instance and >>> > > >subsequent login() >>> > > >calls will just bypass the auth process. >> > > >> > > >> > >If my API doesn't do the login process on the login() call, am I not >> > >failing with the "least surprise principle"? If it doesn't do all the >> > >login procedure when called, better rename it then: mayLogin(), >> > >loginWithCaching() or anything like this. > > > > > >Your usage: > > > >User user = null; > >AuthenticationResult result = identity.login(); > >if(result == AuthenticationResult.SUCCESS){ > >user = identity.getUser(); > >} else { > >throw new RuntimeException("Authentication Failed"); > >} > > > >//Now identity has an user > >//Irrespective of what you want to put in credential, you are > >authenticated already until you logout > >result = identity.login(); > >//result is always SUCCESS. > > >> > > >> > >IMO, this is not only wrong, but I think it can be used as a potential >> > >attack vector. > > > > > >How? >> > > >> > >-- qmx > >_______________________________________________ > >security-dev mailing list > >security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org) > >https://lists.jboss.org/mailman/listinfo/security-dev

I still don't agree with it, we're giving the benefit of the doubt to developers. If I have a method which is invoked twice for example via HTTP request with the following code: >> > >credential.setCredential(x); >> > >identity.login(); > > Login should be validate it again, but if you think that is not a problem, I'm fine. Anil, could you please provide the final solution for it? Examples of usage? -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Wednesday, January 30, 2013 at 1:40 PM, Anil Saldhana wrote: > >On 01/30/2013 09:33 AM, Bruno Oliveira wrote: >> > >So if I'm a bank where the user account is logged in, this user has just forgot to 'logout'. Another person using his computer can just bypass the login, because the session still exists? Banks get over this by frequently being proactive using Javascript. If the user has been idle for a minute, they give out a warning and if there is no response, they log out the user. > > > > >> > >Another scenario, I'm at the same network of John, running my whatever-sniffer, then is just a matter of grab the current session ID and login? Am I wrong? Because If understood correctly, after user login, even if I invoke this method for a second time, what really matters is the session ID. https/ssl should be mandatory for all critical web applications. Just have a HTTP Header agent installed for your browser. Your passwords are in the clear in the http header agent if you do not use https. > > >> > >I'm confused. >> > >-- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Wednesday, January 30, 2013 at 1:17 PM, Anil Saldhana wrote: >> > > >>>> > > > >On 01/29/2013 08:08 PM, Douglas Campos wrote: >>>>>> > > > > > >On Tue, Jan 29, 2013 at 05:19:23PM -0600, Anil Saldhana wrote: >>>>>>>> > > > > > > > >Shane, > > > this is not a bug rather a feature request. >>>>>>> > > > > > > > >>>>>> > > > > > > >>>>> > > > > > >>>> > > > > >>>> > > > > >>>>>>>>>> > > > > > > > > > >it's a bug >>>>>>>> > > > > > > > >Aerogear has the following sequence: > > > > > > credential.setCredential(x); > > > identity.login(); > > > credential.setCredential(y); > > > identity.login(); > > > > > > Aerogear wants PicketLink to reauthenticate during the second login() > > > call. Currently > > > it will not because the first login() established a User instance and > > > subsequent login() > > > calls will just bypass the auth process. >>>>>>> > > > > > > > >>>>>> > > > > > > >>>>> > > > > > >>>> > > > > >>>> > > > > >>>>>>>>>> > > > > > > > > > >If my API doesn't do the login process on the login() call, am I not > > failing with the "least surprise principle"? If it doesn't do all the > > login procedure when called, better rename it then: mayLogin(), > > loginWithCaching() or anything like this. >>> > > > >>>>>> > > > > > >Your usage: > > User user = null; > AuthenticationResult result = identity.login(); > if(result == AuthenticationResult.SUCCESS){ > user = identity.getUser(); > } else { > throw new RuntimeException("Authentication Failed"); > } > > //Now identity has an user > //Irrespective of what you want to put in credential, you are > authenticated already until you logout > result = identity.login(); > //result is always SUCCESS. > >>>>>>>> > > > > > > > >IMO, this is not only wrong, but I think it can be used as a potential > > attack vector. >>>>>>> > > > > > > > >>>>>> > > > > > > >>>>> > > > > > >>>> > > > > >>> > > > >>> > > > >>>>>> > > > > > >How? >>>>>>>> > > > > > > > >-- qmx >>>>>>> > > > > > > > >>>>>> > > > > > > >>>>> > > > > > >>>> > > > > >>> > > > >>> > > > >>>> > > > >_______________________________________________ > security-dev mailing list >security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org) (mailto:security-dev@lists.jboss.org) >https://lists.jboss.org/mailman/listinfo/security-dev >>>>

From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; To: security-dev(a)lists.jboss.org Sent: Wednesday, January 30, 2013 7:31:33 PM Subject: Re: [security-dev] PLINK-84 - Login can be bypassed with any user after a first successful login Actually, I do not see a problem in customizing the behavior of repeated login() method calls: something like: identity.setOption(Option.LOGIN_REPEAT); credential.setCredential(x); identity.login(); credential.setCredential(y); identity.login(); If the option is set, then the second call of login() will authenticate again. By default, we want to maintain the session behavior. But if Aerogear wants repeated login() logic, they should be able to set it in the option? Feedback? On 01/30/2013 11:47 AM, Bruno Oliveira wrote: I still don't agree with it, we're giving the benefit of the doubt to developers. If I have a method which is invoked twice for example via HTTP request with the following code: > > credential.setCredential(x); > > identity.login(); > Login should > > be validate it again, but if you think that is not a problem, > > I'm fine. Anil, could you please provide the final solution for it? Examples of usage? -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Wednesday, January 30, 2013 at 1:40 PM, Anil Saldhana wrote: > On 01/30/2013 09:33 AM, Bruno Oliveira wrote: > > So if I'm a bank where the user account is logged in, this user > > has just forgot to 'logout'. Another person using his computer > > can just bypass the login, because the session still exists? > > Banks get over this by frequently being proactive using > > Javascript. If the user has been idle for a minute, they give > > out a warning and if there is no response, they log out the > > user. > > > > Another scenario, I'm at the same network of John, running my > > whatever-sniffer, then is just a matter of grab the current > > session ID and login? Am I wrong? Because If understood > > correctly, after user login, even if I invoke this method for a > > second time, what really matters is the session ID. https/ssl > > should be mandatory for all critical web applications. Just have > > a HTTP Header agent installed for your browser. Your passwords > > are in the clear in the http header agent if you do not use > > https. > > > I'm confused. > > -- "The measure of a man is what he does with > > power" - Plato - @abstractj - Volenti Nihil Difficile On > > Wednesday, January 30, 2013 at 1:17 PM, Anil Saldhana wrote: > > > > > > On 01/29/2013 08:08 PM, Douglas Campos wrote: > > > > > > On Tue, Jan 29, 2013 at 05:19:23PM -0600, Anil Saldhana > > > > > > wrote: > > > > > > > > Shane, > > > this is not a bug rather a feature > > > > > > > > request. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > it's a bug > > > > > > > > Aerogear has the > > > > > > > > > > following sequence: > > > > > > > > > > > > > > > > credential.setCredential(x); > > > > > > > > > > > > > identity.login(); > > > > > > > > > > > > > credential.setCredential(y); > > > > > > > > > > > > > identity.login(); > > > > > > Aerogear wants > > > > > > > > > > PicketLink to reauthenticate during the second > > > > > > > > > > login() > > > call. Currently > > > it will not > > > > > > > > > > because the first login() established a User > > > > > > > > > > instance and > > > subsequent login() > > > > > > > > > > > > > calls will just bypass the auth process. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If my API doesn't do the login process on the > > > > > > > > > > login() call, am I not > > failing with the > > > > > > > > > > "least surprise principle"? If it doesn't do all > > > > > > > > > > the > > login procedure when called, better > > > > > > > > > > rename it then: mayLogin(), > > > > > > > > > > > > loginWithCaching() or anything like this. > > > > > > > > > Your usage: > > User user = null; > AuthenticationResult > > > > > > result = identity.login(); > if(result == > > > > > > AuthenticationResult.SUCCESS){ > user = > > > > > > identity.getUser(); > } else { > throw new > > > > > > RuntimeException("Authentication Failed"); > } > > //Now > > > > > > identity has an user > //Irrespective of what you want > > > > > > to put in credential, you are > authenticated already > > > > > > until you logout > result = identity.login(); > //result > > > > > > is always SUCCESS. > > > > > > > > > IMO, this is not only wrong, but I think it can be > > > > > > > > used as a potential > > attack vector. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How? > > > > > > > > -- qmx > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > security-dev mailing list > security-dev(a)lists.jboss.org ( > > > > mailto:security-dev@lists.jboss.org ) ( > > > > mailto:security-dev@lists.jboss.org ) > > > > > https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

I see no reason why someone would call login again on an already authenticated session. I believe that Seam 2.x used to catch this and throw an exception (though I could be misremembering). Personally, I would prefer an exception over silently ignoring the call or an option such as the one below. Unless there is a valid reason to call .login again? ----- Original Message ----- > From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; > To: security-dev(a)lists.jboss.org > Sent: Wednesday, January 30, 2013 7:31:33 PM > Subject: Re: [security-dev] PLINK-84 - Login can be bypassed with any user after a first successful login > > > > Actually, I do not see a problem in customizing the behavior of > repeated login() method calls: > > something like: > > identity.setOption(Option.LOGIN_REPEAT); > credential.setCredential(x); > identity.login(); > credential.setCredential(y); > identity.login(); > > If the option is set, then the second call of login() will > authenticate again. > > By default, we want to maintain the session behavior. But if Aerogear > wants repeated login() logic, they should be able to set it in the > option? > > Feedback? > > On 01/30/2013 11:47 AM, Bruno Oliveira wrote: > > > > I still don't agree with it, we're giving the benefit of the doubt to > developers. If I have a method which is invoked twice for example > via HTTP request with the following code: > > > >>> credential.setCredential(x); > > identity.login(); > Login should >>> be validate it again, but if you think that is not a problem, >>> I'm fine. > Anil, could you please provide the final solution for it? Examples of > usage? > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > > > On Wednesday, January 30, 2013 at 1:40 PM, Anil Saldhana wrote: > >> On 01/30/2013 09:33 AM, Bruno Oliveira wrote: >>> So if I'm a bank where the user account is logged in, this user >>> has just forgot to 'logout'. Another person using his computer >>> can just bypass the login, because the session still exists? >>> Banks get over this by frequently being proactive using >>> Javascript. If the user has been idle for a minute, they give >>> out a warning and if there is no response, they log out the >>> user. > > >>> Another scenario, I'm at the same network of John, running my >>> whatever-sniffer, then is just a matter of grab the current >>> session ID and login? Am I wrong? Because If understood >>> correctly, after user login, even if I invoke this method for a >>> second time, what really matters is the session ID. https/ssl >>> should be mandatory for all critical web applications. Just have >>> a HTTP Header agent installed for your browser. Your passwords >>> are in the clear in the http header agent if you do not use >>> https. > >>> I'm confused. > > -- "The measure of a man is what he does with >>> power" - Plato - @abstractj - Volenti Nihil Difficile On >>> Wednesday, January 30, 2013 at 1:17 PM, Anil Saldhana wrote: > > > > >>>>> On 01/29/2013 08:08 PM, Douglas Campos wrote: > > >>>>>>> On Tue, Jan 29, 2013 at 05:19:23PM -0600, Anil Saldhana >>>>>>> wrote: > > >>>>>>>>> Shane, > > > this is not a bug rather a feature >>>>>>>>> request. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> it's a bug > > > > > > > > Aerogear has the >>>>>>>>>>> following sequence: > > > > > > >>>>>>>>>>> credential.setCredential(x); > > > >>>>>>>>>>> identity.login(); > > > >>>>>>>>>>> credential.setCredential(y); > > > >>>>>>>>>>> identity.login(); > > > > > > Aerogear wants >>>>>>>>>>> PicketLink to reauthenticate during the second >>>>>>>>>>> login() > > > call. Currently > > > it will not >>>>>>>>>>> because the first login() established a User >>>>>>>>>>> instance and > > > subsequent login() > > > >>>>>>>>>>> calls will just bypass the auth process. > > > > > > > > > > > > > > >>>>>>>>>>> If my API doesn't do the login process on the >>>>>>>>>>> login() call, am I not > > failing with the >>>>>>>>>>> "least surprise principle"? If it doesn't do all >>>>>>>>>>> the > > login procedure when called, better >>>>>>>>>>> rename it then: mayLogin(), > > >>>>>>>>>>> loginWithCaching() or anything like this. > > > > > > > >>>>>>> Your usage: > > User user = null; > AuthenticationResult >>>>>>> result = identity.login(); > if(result == >>>>>>> AuthenticationResult.SUCCESS){ > user = >>>>>>> identity.getUser(); > } else { > throw new >>>>>>> RuntimeException("Authentication Failed"); > } > > //Now >>>>>>> identity has an user > //Irrespective of what you want >>>>>>> to put in credential, you are > authenticated already >>>>>>> until you logout > result = identity.login(); > //result >>>>>>> is always SUCCESS. > > > >>>>>>>>> IMO, this is not only wrong, but I think it can be >>>>>>>>> used as a potential > > attack vector. > > > > > > > > > > > >>>>>>> How? > > >>>>>>>>> -- qmx > > > > > > > > > > > > > > > > > > > > > > > >>>>> _______________________________________________ > >>>>> security-dev mailing list > security-dev(a)lists.jboss.org ( >>>>> mailto:security-dev@lists.jboss.org ) ( >>>>> mailto:security-dev@lists.jboss.org ) > >>>>> https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

Exactly! That's my point! Thanks Marek. -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Thursday, January 31, 2013 at 8:40 AM, Marek Posolda wrote: > >In Servlet 3.0 specification, method HttpServletRequest.login(username, > >password) stated in javadoc that it throws exception if someone is > >trying to login on already authenticated session. Javadoc looks like this: > > > >* @exception ServletException if the configured login mechanism > >* does not support username > >* password authentication, or > >if a > >* non-null caller identity had > >* already been established > >(prior > >* to the call to login), or if > >* validation of the provided > >* username and password fails. > > > >Indeed throwing exception seems to me like best approach in this case. I > >think that if someone wants to login again with different credentials, > >he should first logout before second login. So usecase could be like: > > > >credential.setCredential(x); > >identity.login(); > >// Do something with identity 'x' > >identity.logout(); > > > >credential.setCredential(y); > >identity.login(); > >// Do something with identity 'y' > > > > > > > >Marek > > > >On 31/01/13 01:58, Jess Sightler wrote: >> > >I see no reason why someone would call login again on an already authenticated session. I believe that Seam 2.x used to catch this and throw an exception (though I could be misremembering). Personally, I would prefer an exception over silently ignoring the call or an option such as the one below. >> > > >> > >Unless there is a valid reason to call .login again? >> > > >> > >----- Original Message ----- >>> > > >From: "Anil Saldhana&quot;&lt;Anil.Saldhana(a)redhat.com (mailto:Anil.Saldhana@redhat.com)> >>> > > >To:security-dev@lists.jboss.org (mailto:security-dev@lists.jboss.org) >>> > > >Sent: Wednesday, January 30, 2013 7:31:33 PM >>> > > >Subject: Re: [security-dev] PLINK-84 - Login can be bypassed with any user after a first successful login >>> > > > >>> > > > >>> > > > >>> > > >Actually, I do not see a problem in customizing the behavior of >>> > > >repeated login() method calls: >>> > > > >>> > > >something like: >>> > > > >>> > > >identity.setOption(Option.LOGIN_REPEAT); >>> > > >credential.setCredential(x); >>> > > >identity.login(); >>> > > >credential.setCredential(y); >>> > > >identity.login(); >>> > > > >>> > > >If the option is set, then the second call of login() will >>> > > >authenticate again. >>> > > > >>> > > >By default, we want to maintain the session behavior. But if Aerogear >>> > > >wants repeated login() logic, they should be able to set it in the >>> > > >option? >>> > > > >>> > > >Feedback? >>> > > > >>> > > >On 01/30/2013 11:47 AM, Bruno Oliveira wrote: >>> > > > >>> > > > >>> > > > >>> > > >I still don't agree with it, we're giving the benefit of the doubt to >>> > > >developers. If I have a method which is invoked twice for example >>> > > >via HTTP request with the following code: >>> > > > >>> > > > >>> > > > >>>>> > > > > >credential.setCredential(x); > > identity.login(); > Login should >>>>> > > > > >be validate it again, but if you think that is not a problem, >>>>> > > > > >I'm fine. >>>>> > > > > > >>>> > > > > >>> > > > >>> > > > >>> > > >Anil, could you please provide the final solution for it? Examples of >>> > > >usage? >>> > > >-- >>> > > >"The measure of a man is what he does with power" - Plato >>> > > >- >>> > > >@abstractj >>> > > >- >>> > > >Volenti Nihil Difficile >>> > > > >>> > > > >>> > > > >>> > > >On Wednesday, January 30, 2013 at 1:40 PM, Anil Saldhana wrote: >>> > > > >>>> > > > >On 01/30/2013 09:33 AM, Bruno Oliveira wrote: >>>>> > > > > >So if I'm a bank where the user account is logged in, this user >>>>> > > > > >has just forgot to 'logout'. Another person using his computer >>>>> > > > > >can just bypass the login, because the session still exists? >>>>> > > > > >Banks get over this by frequently being proactive using >>>>> > > > > >Javascript. If the user has been idle for a minute, they give >>>>> > > > > >out a warning and if there is no response, they log out the >>>>> > > > > >user. > > >>>>> > > > > >Another scenario, I'm at the same network of John, running my >>>>> > > > > >whatever-sniffer, then is just a matter of grab the current >>>>> > > > > >session ID and login? Am I wrong? Because If understood >>>>> > > > > >correctly, after user login, even if I invoke this method for a >>>>> > > > > >second time, what really matters is the session ID. https/ssl >>>>> > > > > >should be mandatory for all critical web applications. Just have >>>>> > > > > >a HTTP Header agent installed for your browser. Your passwords >>>>> > > > > >are in the clear in the http header agent if you do not use >>>>> > > > > >https. > >>>>> > > > > >I'm confused. > > -- "The measure of a man is what he does with >>>>> > > > > >power" - Plato - @abstractj - Volenti Nihil Difficile On >>>>> > > > > >Wednesday, January 30, 2013 at 1:17 PM, Anil Saldhana wrote: > > >>>>> > > > > > >>>> > > > > >>>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>>> > > > > > > >On 01/29/2013 08:08 PM, Douglas Campos wrote: >>> > > > >>> > > > >>>>>>>>> > > > > > > > > >On Tue, Jan 29, 2013 at 05:19:23PM -0600, Anil Saldhana >>>>>>>>> > > > > > > > > >wrote: >>>>>>>>> > > > > > > > > > >>>>>>>> > > > > > > > > >>>>>>> > > > > > > > >>>>>> > > > > > > >>>>> > > > > > >>>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>>>>>>> > > > > > > > > > > >Shane, > > > this is not a bug rather a feature >>>>>>>>>>> > > > > > > > > > > >request. > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > >>>>>>>>> > > > > > > > > > >>>>>>>> > > > > > > > > >>>>>>> > > > > > > > >>>>>> > > > > > > >>>>> > > > > > >>>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>>>>>>>>> > > > > > > > > > > > > >it's a bug > > > > > > > > Aerogear has the >>>>>>>>>>>>> > > > > > > > > > > > > >following sequence: > > > > > > >>>>>>>>>>>>> > > > > > > > > > > > > >credential.setCredential(x); > > > >>>>>>>>>>>>> > > > > > > > > > > > > >identity.login(); > > > >>>>>>>>>>>>> > > > > > > > > > > > > >credential.setCredential(y); > > > >>>>>>>>>>>>> > > > > > > > > > > > > >identity.login(); > > > > > > Aerogear wants >>>>>>>>>>>>> > > > > > > > > > > > > >PicketLink to reauthenticate during the second >>>>>>>>>>>>> > > > > > > > > > > > > >login() > > > call. Currently > > > it will not >>>>>>>>>>>>> > > > > > > > > > > > > >because the first login() established a User >>>>>>>>>>>>> > > > > > > > > > > > > >instance and > > > subsequent login() > > > >>>>>>>>>>>>> > > > > > > > > > > > > >calls will just bypass the auth process. > > > > >>>>>>>>>>>>> > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > >>>>>>>>> > > > > > > > > > >>>>>>>> > > > > > > > > >>>>>>> > > > > > > > >>>>>> > > > > > > >>>>> > > > > > >>>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>>>>>>>>> > > > > > > > > > > > > >If my API doesn't do the login process on the >>>>>>>>>>>>> > > > > > > > > > > > > >login() call, am I not > > failing with the >>>>>>>>>>>>> > > > > > > > > > > > > >"least surprise principle"? If it doesn't do all >>>>>>>>>>>>> > > > > > > > > > > > > >the > > login procedure when called, better >>>>>>>>>>>>> > > > > > > > > > > > > >rename it then: mayLogin(), > > >>>>>>>>>>>>> > > > > > > > > > > > > >loginWithCaching() or anything like this. > > > >>>>>>>>>>>>> > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > >>>>>>>>> > > > > > > > > > >>>>>>>> > > > > > > > > >>>>>>> > > > > > > > >>>>>> > > > > > > >>>>> > > > > > >>>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>>>>> > > > > > > > > >Your usage: > > User user = null; > AuthenticationResult >>>>>>>>> > > > > > > > > >result = identity.login(); > if(result == >>>>>>>>> > > > > > > > > >AuthenticationResult.SUCCESS){ > user = >>>>>>>>> > > > > > > > > >identity.getUser(); > } else { > throw new >>>>>>>>> > > > > > > > > >RuntimeException("Authentication Failed"); > } > > //Now >>>>>>>>> > > > > > > > > >identity has an user > //Irrespective of what you want >>>>>>>>> > > > > > > > > >to put in credential, you are > authenticated already >>>>>>>>> > > > > > > > > >until you logout > result = identity.login(); > //result >>>>>>>>> > > > > > > > > >is always SUCCESS. > >>>>>>>>> > > > > > > > > > >>>>>>>> > > > > > > > > >>>>>>> > > > > > > > >>>>>> > > > > > > >>>>> > > > > > >>>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>>>>>>> > > > > > > > > > > >IMO, this is not only wrong, but I think it can be >>>>>>>>>>> > > > > > > > > > > >used as a potential > > attack vector. > > > > > > > >>>>>>>>>>> > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > >>>>>>>>> > > > > > > > > > >>>>>>>> > > > > > > > > >>>>>>> > > > > > > > >>>>>> > > > > > > >>>>> > > > > > >>>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>>>>> > > > > > > > > >How? >>> > > > >>> > > > >>>>>>>>>>> > > > > > > > > > > >-- qmx > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>

So if I'm a bank where the user account is logged in, this user has just forgot to 'logout'. Another person using his computer can just bypass the login, because the session still exists? Another scenario, I'm at the same network of John, running my whatever-sniffer, then is just a matter of grab the current session ID and login? Am I wrong? Because If understood correctly, after user login, even if I invoke this method for a second time, what really matters is the session ID.

I'm confused.