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" <Anil.Saldhana(a)redhat.com
(mailto:Anil.Saldhana@redhat.com)>
> > To: security-dev(a)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 > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > _______________________________________________ >
> > > > > > security-dev mailing list > security-dev(a)lists.jboss.org
(mailto:security-dev@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 (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
>
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/security-dev