[JBoss JIRA] Created: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
2:55 p.m.
ClientLoginModule improperly handles SecurityAssociation stack in abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Marco Schulze
Assignee: Anil Saldhana
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:44 a.m.
New subject: [JBoss JIRA] Updated: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Anil Saldhana updated SECURITY-339:
-----------------------------------
Component/s: JBossSX
Fix Version/s: JBossSecurity_2.0.4
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:53 p.m.
New subject: [JBoss JIRA] Closed: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Anil Saldhana closed SECURITY-339.
----------------------------------
Resolution: Done
On abort, the principal information if any should be popped from the Security Context.
Apart from the code is fine.
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:33 p.m.
New subject: [JBoss JIRA] Commented: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Marco Schulze commented on SECURITY-339:
----------------------------------------
I just took a look at
http://fisheye.jboss.org/browse/JBossAS/projects/security/security-jboss-...
and the code is still wrong!
You wrote in your comment "On abort, the principal information if any should be
popped from the Security Context." This is *NOT* correct, because the login module
must only pop things which it pushed itself before. Otherwise it pops sth. that has been
pushed by *ANOTHER* login process before.
I have - before submitting this issue - stepped through the code thoroughly and saw that
the methods called by a normal login are as follows:
A) if successful:
1) ClientLoginModule.login()
2) ClientLoginModule.commit()
B) on error:
1) ClientLoginModule.login()
2) ClientLoginModule.abort()
Since the current code pushes the principal onto the stack in the commit() method (i.e.
only if successful) but the abort() method pops it even though no commit() happened, the
stack is wrong after one single authentication failure!
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:33 p.m.
New subject: [JBoss JIRA] Reopened: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Marco Schulze reopened SECURITY-339:
------------------------------------
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:46 p.m.
New subject: [JBoss JIRA] Commented: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Marco Schulze commented on SECURITY-339:
----------------------------------------
I just took a look at the test cases in
http://fisheye.jboss.org/browse/JBossAS/projects/security/security-jboss-...
and I'm pretty sure it does *NOT* test a situation in which the bug described by this
issue can be reproduced.
If I see it correctly, it tests only once for abort. But this test does not have multiple
stacked logins and thus the wrong behaviour of the abort method can not be demonstrated.
Let me explain in a small example what goes wrong. Imagine we have two login processes
happening and thus 2 principals are to be stacked. The first to authenticate is user1 and
the second is user2.
If both logins succeed, it looks like this:
A1) ClientLoginModule.login() called for user1. No change on the stack yet!
A2) ClientLoginModule.commit() called for user1. user1 is now the only item on the stack.
A3) ClientLoginModule.login() called for user2. No change on the stack yet! user1 is still
the only item on the stack.
A4) ClientLoginModule.commit() called for user2. user2 is now the last item on the stack.
Now the logouts would come in reverse order:
A5) ClientLoginModule.logout() called for user2. user2 is popped from the stack. user1 is
the only item on the stack, now.
A6) ClientLoginModule.logout() called for user1. user1 is popped from the stack. The stack
is empty now.
If the first login succeeds and the second login fails, however, things are completely
different:
B1) ClientLoginModule.login() called for user1. No change on the stack yet!
B2) ClientLoginModule.commit() called for user1. user1 is now the only item on the stack.
B3) ClientLoginModule.login() called for user2. No change on the stack yet! user1 is still
the only item on the stack.
B4) Some other login module failed during login, thus ClientLoginModule.abort() is called
for user2. The current wrong code wants to pop user2 from the stack, but since user2 is
not on the stack, it instead pops user1.
I hope that it is now clear why the code is wrong.
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:51 p.m.
New subject: [JBoss JIRA] Commented: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Marco Schulze commented on SECURITY-339:
----------------------------------------
I just wanted to add one thought:
If it is possible in certain scenarios that both commit() and abort() are called, then the
login module must track in a boolean field, if commit() was called. Only then, it must pop
the principal in its abort() method.
I never had this scenario, hence I'm not sure if this can really ever happen. But it
is definitely wrong to always pop in abort(), because at least in all situations, which I
debugged, the abort() method was called without commit() happening before.
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:15 p.m.
New subject: [JBoss JIRA] Commented: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Anil Saldhana commented on SECURITY-339:
----------------------------------------
You need to set the "multi-threaded" property to true to obtain the isolation.
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:26 p.m.
New subject: [JBoss JIRA] Commented: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Marco Schulze commented on SECURITY-339:
----------------------------------------
Dear Anil,
thanks for your quick reply. I'm sorry to say, though, that your hint about the
"multi-threaded" property has nothing, really absolutely nothing to do with the
wrong behaviour that I described here in this issue.
First, I kindly ask you to read my last 2 comments again: It is *not* about different
threads colliding! It is about nested (stacked) logins on the *same* *thread*. And
that's IMHO the sole purpose of the property "restore-login-identity"!
Second, let me point you to the javadoc of ClientLoginModule:
"multi-threaded=[true|false]
When the multi-threaded option is set to true, the SecurityAssociation.setServer()
so that each login thread has its own principal and credential storage."
The "SecurityAssociation.setServer()" has definitely been called in the server
already. It is a *global* (i.e. JVM-wide) flag and I have - of course - debugged this a
long time ago. It is always true in the JBoss - at least I never saw this flag being
false.
Third, let me kindly ask you to look at the initialize(...) method and you'll see
that
- the javadoc is correct and setting this option has really only this one effect,
- the SecurityAssociation.setClient() is only called if you explicitely set this property
to "false", which I (of course) don't do.
Finally, I'd like to mention that I was of course not able to wait for this bug being
fixed and therefore have implemented the correct behaviour (as described in detail in this
issue) into my "real" login-module. Before I was using both login-modules
together. But after having found this bug, I dropped the
org.jboss.security.ClientLoginModule from my login configuration.
I say this, because my login module works absolutely fine and thus proves my error
descriptions as well as my suggested bugfix correct. Thus, please take a look at:
https://svn-de.nightlabs.org/svn/jfire-main/branches/jfire_1.0/JFireInteg...
Best regards, Marco :-)
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:53 a.m.
New subject: [JBoss JIRA] Commented: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Marco Schulze commented on SECURITY-339:
----------------------------------------
Just wanted to note: I have added the boolean flag to my login-module today to cope with
the situation that abort() is called after commit() even though I still doubt whether this
can ever happen.
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:32 p.m.
New subject: [JBoss JIRA] Commented: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Anil Saldhana commented on SECURITY-339:
----------------------------------------
Marco, I was looking at the problem for a parallel/concurrent logins happening in the
system and did not visualize the issue from sequential logins perspective. I think you
have a point. We will create test cases to recreate this situation and fix it before
2.0.4
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:11 p.m.
New subject: [JBoss JIRA] Resolved: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Anil Saldhana resolved SECURITY-339.
------------------------------------
Resolution: Done
In JBoss AS 5.x, we have deprecated SecurityAssociation and are using a construct called
as SecurityContext. I have tested the scenarios you mentioned here:
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s...
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:59 p.m.
New subject: [JBoss JIRA] Reopened: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Anil Saldhana reopened SECURITY-339:
------------------------------------
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:22 p.m.
New subject: [JBoss JIRA] Resolved: (SECURITY-339) ClientLoginModule improperly handles SecurityAssociation stack in abort()
[
https://jira.jboss.org/jira/browse/SECURITY-339?page=com.atlassian.jira.p...
]
Anil Saldhana resolved SECURITY-339.
------------------------------------
Resolution: Done
ClientLoginModule improperly handles SecurityAssociation stack in
abort()
-------------------------------------------------------------------------
Key: SECURITY-339
URL: https://jira.jboss.org/jira/browse/SECURITY-339
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JBossSX
Reporter: Marco Schulze
Assignee: Anil Saldhana
Fix For: JBossSecurity_2.0.4
The abort() method calls SecurityAssociationActions.popPrincipalInfo() even though the
corresponding push happens in commit() [via
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject)].
That means, whenever a login fails, the commit is not called (thus nothing pushed), but
the abort pops out an element from the stack. This should not be done. IMHO the abort()
method should look like this:
public boolean abort() throws LoginException
{
if( trace )
log.trace("abort");
if( restoreLoginIdentity == false )
{
// Clear the entire security association stack
SecurityAssociationActions.clear();
}
return true;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5898
days inactive
6145
days old
13 comments
2 participants
participants (2)
-
Anil Saldhana (JIRA) -
Marco Schulze (JIRA)