[JBoss JIRA] (SECURITY-659) WebJASPIAuthenticator ignores GroupPrincipalCallback but requires PasswordValidationCallback
by arjan tijms (JIRA)
arjan tijms created SECURITY-659:
------------------------------------
Summary: WebJASPIAuthenticator ignores GroupPrincipalCallback but requires PasswordValidationCallback
Key: SECURITY-659
URL: https://issues.jboss.org/browse/SECURITY-659
Project: PicketBox (JBoss Security and Identity Management)
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PicketBox
Affects Versions: PicketBox_v4_0_7
Reporter: arjan tijms
Assignee: Anil Saldhana
In JBoss AS 7.1.1, if a user provided {{ServerAuthModule}} provides a {{GroupPrincipalCallback}}, then this is ignored by {{WebJASPIAuthenticator}}. The provided handler copies the {{GroupPrincipalCallback}}, but the authenticator then does nothing with it. Simulteanously, if the {{ServerAuthModule}} does not provide a {{PasswordValidationCallback}} to the handler, then this will result in a null pointer exception in the authenticator.
Regarding the ignored {{GroupPrincipalCallback}}, the problem seems to be in the following code:
{code:title=WebJASPIAuthenticator#authenticate}
// ...
if (result) {
PasswordValidationCallback pvc = cbh.getPasswordValidationCallback();
CallerPrincipalCallback cpc = cbh.getCallerPrincipalCallback();
// get the client principal from the callback.
Principal clientPrincipal = cpc.getPrincipal();
if (clientPrincipal == null) {
clientPrincipal = new SimplePrincipal(cpc.getName());
}
// if the client principal is not a jboss generic principal, we need to build one before registering.
if (!(clientPrincipal instanceof JBossGenericPrincipal))
clientPrincipal = this.buildJBossPrincipal(clientSubject, clientPrincipal);
{code}
{{buildJBossPrincipal()}} looks at the "Roles" group in the Subject, but this hasn't been set by either the handler or other code based on what the GroupPrincipalCallback contains.
I wonder if changing this into the following would be more correct:
{code:title=WebJASPIAuthenticator#authenticate}
// ...
if (result) {
PasswordValidationCallback pvc = cbh.getPasswordValidationCallback();
CallerPrincipalCallback cpc = cbh.getCallerPrincipalCallback();
GroupPrincipalCallback gpc = cbh.getGroupPrincipalCallback(); // ADDED
// get the client principal from the callback.
Principal clientPrincipal = cpc.getPrincipal();
if (clientPrincipal == null) {
clientPrincipal = new SimplePrincipal(cpc.getName());
}
// if the client principal is not a jboss generic principal, we need to build one before registering.
if (!(clientPrincipal instanceof JBossGenericPrincipal))
clientPrincipal = this.buildJBossPrincipal(clientSubject, clientPrincipal, gpc); // ADDED gpc PARAMETER
{code}
With {{buildJBossPrincipal()}} implemented as:
{code:title=WebJASPIAuthenticator#buildJBossPrincipal}
protected Principal buildJBossPrincipal(Subject subject, Principal principal, GroupPrincipalCallback groupPrincipalCallback) {
List<String> roles = new ArrayList<String>();
// look for roles in the subject first.
for (Principal p : subject.getPrincipals()) {
if (p instanceof Group && p.getName().equals("Roles")) {
Enumeration<? extends Principal> members = ((Group) p).members();
while (members.hasMoreElements())
roles.add(members.nextElement().getName());
}
}
// START ADDED
if (groupPrincipalCallback != null && groupPrincipalCallback.getGroups() != null) {
for (String group : groupPrincipalCallback.getGroups()) {
roles.add(group);
}
}
// END ADDED
// if the subject didn't contain any roles, look for the roles declared in the deployment descriptor.
JBossWebRealm realm = (JBossWebRealm) this.getContainer().getRealm();
Set<String> descriptorRoles = realm.getPrincipalVersusRolesMap().get(principal.getName());
if (roles.isEmpty() && descriptorRoles != null)
roles.addAll(descriptorRoles);
// build and return the JBossGenericPrincipal.
return new JBossGenericPrincipal(realm, principal.getName(), null, roles, principal, null, null, null, subject);
}
{code}
As for the PasswordValidationCallback, WebJASPIAuthenticator now contains the following code in {{authenticate()}}:
{code:title=WebJASPIAuthenticator#authenticate}
this.register(request, response, clientPrincipal, authMethod, pvc.getUsername(),
new String(pvc.getPassword()));
{code}
The {{register()}} method considers both username and password as optional, but because there's no null check on {{pvc}}, the above line will throw a NPE in case no PasswordValidationCallback is provided. This could perhaps be changed into something like the following:
{code:title=WebJASPIAuthenticator#authenticate}
this.register(request, response, clientPrincipal, authMethod, pvc != null ? pvc.getUsername() : null,
pvc != null ? new String(pvc.getPassword()) : null);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson edited comment on AS7-5907 at 11/8/12 10:01 AM:
--------------------------------------------------------------
This was deferred in JBTM, but I think it might be something AS7 would like to provide for usability aspects.
Generally: assuming the user does not define the node-identifier themselves, use Cleberts algorithm to persistently store a unique node-identifier.
Note the node-identifier must be unique for any server that talks to another server or shares an object store, it may be that UUID is not considered to be guaranteed to be unique enough.
was (Author: tomjenkinson):
This was deferred in JBTM, but I think it might be something AS7 would like to provide for usability aspects.
Generally: assuming the user does not define the node-identifier themselves, use Cleberts algorithm to persistently store a unique node-identifier.
Note the node-identifier must be unique for any server that talks to another server or shares an object store, it may be that UUID is not considered unique enough.
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: AS7-5907
> URL: https://issues.jboss.org/browse/AS7-5907
> Project: Application Server 7
> Issue Type: Feature Request
> Reporter: Clebert Suconic
> Assignee: Stefano Maestri
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ]
Clebert Suconic commented on AS7-5907:
--------------------------------------
This would save us a lot of hassle with users not setting the proper NodeID when in cluster.
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: AS7-5907
> URL: https://issues.jboss.org/browse/AS7-5907
> Project: Application Server 7
> Issue Type: Feature Request
> Reporter: Clebert Suconic
> Assignee: Stefano Maestri
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson commented on AS7-5907:
------------------------------------
This was deferred in JBTM, but I think it might be something AS7 would like to provide for usability aspects.
Generally: assuming the user does not define the node-identifier themselves, use Cleberts algorithm to persistently store a unique node-identifier.
Note the node-identifier must be unique for any server that talks to another server or shares an object store, it may be that UUID is not considered unique enough.
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: AS7-5907
> URL: https://issues.jboss.org/browse/AS7-5907
> Project: Application Server 7
> Issue Type: Feature Request
> Reporter: Clebert Suconic
> Assignee: Stefano Maestri
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ]
Clebert Suconic commented on AS7-5907:
--------------------------------------
I chat I had with Tom Jenkinson:
clebert: tomjenkinson: but now you have compatibility issues to deal
[08:56am] clebert: tomjenkinson: what if you start a new version...
[08:56am] clebert: you didn't have the data there.. then you will add it
[08:56am] clebert: tomjenkinson: you would have to only set the UUID if there is no data folder.. no Objects pending at all
[08:57am] clebert: tomjenkinson: well.. you can easily do a check on.. if (objects.counts() == 0) and ID=default, ID = new UUID, store it on the folder and recover on restart
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: AS7-5907
> URL: https://issues.jboss.org/browse/AS7-5907
> Project: Application Server 7
> Issue Type: Feature Request
> Reporter: Clebert Suconic
> Assignee: Stefano Maestri
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson moved JBTM-1157 to AS7-5907:
------------------------------------------
Project: Application Server 7 (was: JBoss Transaction Manager)
Key: AS7-5907 (was: JBTM-1157)
Security: (was: Public)
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: AS7-5907
> URL: https://issues.jboss.org/browse/AS7-5907
> Project: Application Server 7
> Issue Type: Feature Request
> Reporter: Clebert Suconic
> Assignee: Tom Jenkinson
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated AS7-5907:
-------------------------------
Assignee: Stefano Maestri (was: Tom Jenkinson)
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: AS7-5907
> URL: https://issues.jboss.org/browse/AS7-5907
> Project: Application Server 7
> Issue Type: Feature Request
> Reporter: Clebert Suconic
> Assignee: Stefano Maestri
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson reopened AS7-5907:
--------------------------------
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: AS7-5907
> URL: https://issues.jboss.org/browse/AS7-5907
> Project: Application Server 7
> Issue Type: Feature Request
> Reporter: Clebert Suconic
> Assignee: Stefano Maestri
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-5729) How to prevent mod_cluster as single point failure?
by hitesh yadav (JIRA)
hitesh yadav created AS7-5729:
---------------------------------
Summary: How to prevent mod_cluster as single point failure?
Key: AS7-5729
URL: https://issues.jboss.org/browse/AS7-5729
Project: Application Server 7
Issue Type: Feature Request
Components: Web
Affects Versions: 7.1.0.Final
Environment: i have used Windows 7 as OS .
Reporter: hitesh yadav
Assignee: Remy Maucherat
Priority: Optional
My requirement is to make 2 or more node in a clustering to get High Availability.
In my configuration i have used two nodes in a domain mode for clustering.
I have used mod_cluster for load balancing.
If node which install Apche+mod_cluster crash the whole things stop.
Is there any way to make two mod_cluster in Active/Passive format in a such a way that when one of them crash another mod_cluster activated and start working without any interruption.
Is there any way to make two mod_cluster to check health status of each other.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months