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>
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