[JBoss JIRA] Created: (SECURITY-255) IdentityLoginModule Incomplete password-stacking useFirstPass implementation
by Darran Lofthouse (JIRA)
IdentityLoginModule Incomplete password-stacking useFirstPass implementation
----------------------------------------------------------------------------
Key: SECURITY-255
URL: http://jira.jboss.com/jira/browse/SECURITY-255
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBossSX
Affects Versions: 2.0.2.CR6
Reporter: Darran Lofthouse
Assigned To: Darran Lofthouse
Fix For: 2.0.3.Beta2
The IdentityLoginModule has got an incomplete useFirstPass implementation.
The login() method does start with: -
if( super.login() == true )
return true;
To skip login if useFirstPass is set and authentication has already occurred.
However at the end of login() setting the principal in the shared state map should only happen if useFirstPass was set.
Also for this to work a credential also needs to be stored in the sharedStateMap otherwise other modules will assume authentication has not occurred.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] Created: (SECURITY-352) Cache Server Subject
by Darran Lofthouse (JIRA)
Cache Server Subject
--------------------
Key: SECURITY-352
URL: https://jira.jboss.org/jira/browse/SECURITY-352
Project: JBoss Security and Identity Management
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Negotiation
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: Negotiation_2.0.4.GA
Each authentication process currently has 3 AS-REQ requests (6 if pre-auth is an issue)
One request for each of the SPNEGO round trips and then one request for the LDAP search.
Attempts to make use of a local ticket cache failed: -
<!--
<module-option name="useTicketCache">true</module-option>
<module-option name="renewTGT">true</module-option>
<module-option name="ticketCache">/home/darranl/src/negotiation-as/jboss-4.2.2.GA-AD/testserver.cache</module-option>
-->
As the keytab had not been read it meant that the requirements for storeKey were not met, this is needed for SPNEGO.
<module-option name="storeKey">true</module-option>
A mechanism to cache the server subject is needed.
The expiration time of the ticket can be obtained to decide how long to cache the ticket for: -
Set<Object> privateCredentials = serverSubject.getPrivateCredentials();
for (Object current : privateCredentials)
{
if (current instanceof KerberosTicket)
{
KerberosTicket ticket = (KerberosTicket) current;
System.out.println(ticket.getEndTime());
}
}
--
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 years, 11 months
[JBoss JIRA] Created: (SECURITY-573) Improve handling of IOException thrown from NegotiationAuthenticator
by Marek Posolda (JIRA)
Improve handling of IOException thrown from NegotiationAuthenticator
--------------------------------------------------------------------
Key: SECURITY-573
URL: https://issues.jboss.org/browse/SECURITY-573
Project: PicketBox (JBoss Security and Identity Management)
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Negotiation
Affects Versions: Negotiation_2.0.3.GA
Environment: JBoss EPP 5.1.GA with SPNEGO support, JBoss Negotiation 2.0.3, commons-http-client 3.1 used as HTTP client
Reporter: Marek Posolda
Assignee: Darran Lofthouse
Fix For: Negotiation_2.0.4
Currently if IOException is thrown from NegotiationAuthenticator (For example from line 123 from statement: NegotiationMessage requestMessage = mf.createMessage(authTokenIS); )
then this exception is never logged but it's catched and ignored in CoyoteAdapter.service. Result is that client receives response code 200 OK and emtpy HTTP response. And there is nothing in server log, which can be used to recognize error. So I need to debug if I want to find the real cause of IO issue.
Example for simulating of this issue can be using of Kerberos OID instead of SPNEGO OID as described in Jira SECURITY-572
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months