Topic
  • 4 replies
  • Latest Post - ‏2013-02-26T04:52:06Z by kark
SystemAdmin
SystemAdmin
590 Posts

Pinned topic WebSphere 8.5 validates username and groups for JASPIC module?

‏2013-02-06T16:34:53Z |
I'm trying to build a JASPIC module that's compatible with a wide range of application servers (as per the primary JASPIC use case).

An experimental SAM just contains the following code in its validateRequest method:

CallerPrincipalCallback callerPrincipalCallback =
new CallerPrincipalCallback(clientSubject, "test");

GroupPrincipalCallback groupPrincipalCallback =
new GroupPrincipalCallback(
clientSubject, new String[] { "architect" }
);

try {
handler.handle(new Callback[] { callerPrincipalCallback, groupPrincipalCallback });
} catch (IOException | UnsupportedCallbackException e) {
e.printStackTrace();
}

See http://arjan-tijms.blogspot.com/2012/11/implementing-container-authentication.html

This SAM runs on GlassFish, WebLogic, Geronimo and JBoss EAP.

However, on WebSphere I could not get the SAM to validate requests without creating a user with name "test" and a group with name "architect" in the WebSphere admin console (Users and Groups -> Manage Users -> Create, etc). Apparently, the WebSphere CallbackHandler does some kind of validation to see if both the user and the group exist. The alternative Hashtable method (which is the thing the callback handler is doing behind the scenes?), documented at http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Fae%2Ftsec_jaspi_create.html more or less states this requirement in code:

UserRegistry reg = RegistryHelper.getUserRegistry(null);
String uniqueid = reg.getUniqueUserID(username);

Hashtable hashtable = new Hashtable();
hashtable.put(AttributeNameConstants.WSCREDENTIAL_UNIQUEID, uniqueid);
hashtable.put(AttributeNameConstants.WSCREDENTIAL_SECURITYNAME, username);

In the above code fragment, "WSCREDENTIAL_SECURITYNAME" can be set without problems, but "WSCREDENTIAL_UNIQUEID" can seemingly only be set if WebSpere internally knows about the user (if the UserRegistry returns by the RegistryHelper somehow knows the user). If "WSCREDENTIAL_UNIQUEID" isn't (correctly) set, then authentication fails and a "SECJ0056E: Authentication failed for reason <NULL>" is printed in the logs.

But if the SAM is in control of fetching the users and groups from whatever custom repository it manages/and or connects to, then WebSphere can't possibly know about these users and groups in advance, can it?

How can I tell WebSphere not to do this validation or these internal lookups?
  • SystemAdmin
    SystemAdmin
    590 Posts

    Re: WebSphere 8.5 validates username and groups for JASPIC module?

    ‏2013-02-23T16:31:15Z  
    Is there nobody from IBM who can answer this?

    I really would like to test my SAM on WebSphere as well, but the user names come from an external source. It's pretty much undoable to manually add a user in the IBM WebSphere admin console for every external user. This also makes it impossible to add users during run-time.

    Surely this can't be what is really required?
  • kark
    kark
    26 Posts

    Re: WebSphere 8.5 validates username and groups for JASPIC module?

    ‏2013-02-25T03:33:38Z  
    Is there nobody from IBM who can answer this?

    I really would like to test my SAM on WebSphere as well, but the user names come from an external source. It's pretty much undoable to manually add a user in the IBM WebSphere admin console for every external user. This also makes it impossible to add users during run-time.

    Surely this can't be what is really required?
    Hi,

    Sorry for the delay.

    You should be able to use the hashtable login as you described without the user being required to be in the WebSphere user registry. If the hashtable properties are specified, the WebSphere code will use that to create the subject w/o having to go to the registry during authentication. You can also set the groups using the WSCREDENTIAL_GROUPS attribute. FYI.. The uniqueID is used by WebSphere internally to handle the authorization (i.e it checks to make sure that uniqueIDs of the user and group match instead of just the user/group name which may not be unique).

    What is the value that you are passing for the uniqueID? Did you just try to put the user name and see? We might need to look at the com.ibm.ws.security.*=trace to see what might be going wrong here. You can also open a problem report with IBM support to investigate this more.

    --Ajay
  • SystemAdmin
    SystemAdmin
    590 Posts

    Re: WebSphere 8.5 validates username and groups for JASPIC module?

    ‏2013-02-25T22:21:13Z  
    • kark
    • ‏2013-02-25T03:33:38Z
    Hi,

    Sorry for the delay.

    You should be able to use the hashtable login as you described without the user being required to be in the WebSphere user registry. If the hashtable properties are specified, the WebSphere code will use that to create the subject w/o having to go to the registry during authentication. You can also set the groups using the WSCREDENTIAL_GROUPS attribute. FYI.. The uniqueID is used by WebSphere internally to handle the authorization (i.e it checks to make sure that uniqueIDs of the user and group match instead of just the user/group name which may not be unique).

    What is the value that you are passing for the uniqueID? Did you just try to put the user name and see? We might need to look at the com.ibm.ws.security.*=trace to see what might be going wrong here. You can also open a problem report with IBM support to investigate this more.

    --Ajay
    Hi kark, thanks for your reply

    > {quote:title=kark wrote:}{quote}
    > You should be able to use the hashtable login as you described without the user being required to be in the WebSphere user registry. If the hashtable properties are specified, the WebSphere code will use that to create the subject w/o having to go to the registry during authentication.

    Unfortunately, that wouldn't be quite ideal even if it would work. The thing is that the JASPIC auth module is supposed to be portable between all application servers (which is the entire idea behind JASPIC). Having WebSphere specific code in such module isn't really helping then.
    > FYI.. The uniqueID is used by WebSphere internally to handle the authorization (i.e it checks to make sure that uniqueIDs of the user and group match instead of just the user/group name which may not be unique).

    But do you know how that is supposed to work in practice then? The JASPIC module contacts an external location and does the authentication and subsequent role/group fetching based on that. Say, the external location is an OpenID provider. Should all the users from such a provider be transferred to this internal WebSphere registry? (in case of big public OpenID providers this is basically impossible)
    > What is the value that you are passing for the uniqueID? Did you just try to put the user name and see?

    I'm not explicitly providing a "uniqueID" really, but I'm using the CallBackHandler that WebSphere passes to my auth module as per the WebSphere documentation and JASPIC spec. A simplified example:

    public AuthStatus validateRequest(MessageInfo messageInfo, Subject clientSubject, Subject serviceSubject) throws AuthException {

    // http://...

    CallerPrincipalCallback callerPrincipalCallback = new CallerPrincipalCallback(clientSubject, "test");

    // handler is the CallBackHandler WebSphere passed into the auth module (a com.ibm.ws.security.web.JaspiCallbackHandler)
    handler.handle(new Callback[] { callerPrincipalCallback });

    // http://...
    }

    In this case I'm passing "test" to the CallPrincipalCallback and I expect that this "test" will be directly accepted (as the code in the JASPIC auth module is supposed to have the final say in what the user/caller principal name will become). Each and every JASPIC implementation I tested (GlassFish, JBoss AS/EAP, WebLogic, Geronimo and Jety) indeed accepts this name directly. WebSphere thus far is the only implementation that quite unexpectedly does its own validation outside the control of the JASPIC auth module.

    > We might need to look at the com.ibm.ws.security.*=trace to see what might be going wrong here.

    Well, that could be an option indeed. I did get some data that might be helpful here already. After some digging in debug mode and by stepping into the code and inspecting the variables, I discovered the following. The issue seems to be primarily with the com.ibm.ws.security.web.JaspiCallbackHandler. Upon calling its handle method, there is at some point a call to a method named handleCallerPrincipalCallback and then to addUniqueIdAndGroupsForUser. This then does a call to registry.isValidUser, which I suspect is the culprit.

    If I enter a the name of a user that I added to WebSphere, the above mentioned registry.isValidUser returns true, and two entries will be set by the handler: "com.ibm.wsspi.security.cred.uniqueId" and "com.ibm.wsspi.security.cred.groups". If the handle method now returns, clientSubject.privCredentials will contain the following entries:

    com.ibm.wsspi.security.cred.uniqueId=user:defaultWIMFileBasedRealm/uid=test,o=defaultWIMFileBasedRealm
    com.ibm.wsspi.security.cred.securityName=test
    com.ibm.wsspi.security.cred.groups=[]

    Now if I pass the name of a user that I did not add to WebSphere, say "testnotinwebsphere" to the CallerPrincipalCallback then clientSubject.privCredentials will only contain the following entry after the handle call:

    com.ibm.wsspi.security.cred.securityName=testnotinwebsphere

    If you would like to test this for yourself, the full test code is as described here: http://arjan-tijms.blogspot.com/2012/11/implementing-container-authentication.html and it can be downloaded directly from https://code.google.com/p/javaee6-auth-example/source/browse
  • kark
    kark
    26 Posts

    Re: WebSphere 8.5 validates username and groups for JASPIC module?

    ‏2013-02-26T04:52:06Z  
    Hi kark, thanks for your reply

    > {quote:title=kark wrote:}{quote}
    > You should be able to use the hashtable login as you described without the user being required to be in the WebSphere user registry. If the hashtable properties are specified, the WebSphere code will use that to create the subject w/o having to go to the registry during authentication.

    Unfortunately, that wouldn't be quite ideal even if it would work. The thing is that the JASPIC auth module is supposed to be portable between all application servers (which is the entire idea behind JASPIC). Having WebSphere specific code in such module isn't really helping then.
    > FYI.. The uniqueID is used by WebSphere internally to handle the authorization (i.e it checks to make sure that uniqueIDs of the user and group match instead of just the user/group name which may not be unique).

    But do you know how that is supposed to work in practice then? The JASPIC module contacts an external location and does the authentication and subsequent role/group fetching based on that. Say, the external location is an OpenID provider. Should all the users from such a provider be transferred to this internal WebSphere registry? (in case of big public OpenID providers this is basically impossible)
    > What is the value that you are passing for the uniqueID? Did you just try to put the user name and see?

    I'm not explicitly providing a "uniqueID" really, but I'm using the CallBackHandler that WebSphere passes to my auth module as per the WebSphere documentation and JASPIC spec. A simplified example:

    public AuthStatus validateRequest(MessageInfo messageInfo, Subject clientSubject, Subject serviceSubject) throws AuthException {

    // http://...

    CallerPrincipalCallback callerPrincipalCallback = new CallerPrincipalCallback(clientSubject, "test");

    // handler is the CallBackHandler WebSphere passed into the auth module (a com.ibm.ws.security.web.JaspiCallbackHandler)
    handler.handle(new Callback[] { callerPrincipalCallback });

    // http://...
    }

    In this case I'm passing "test" to the CallPrincipalCallback and I expect that this "test" will be directly accepted (as the code in the JASPIC auth module is supposed to have the final say in what the user/caller principal name will become). Each and every JASPIC implementation I tested (GlassFish, JBoss AS/EAP, WebLogic, Geronimo and Jety) indeed accepts this name directly. WebSphere thus far is the only implementation that quite unexpectedly does its own validation outside the control of the JASPIC auth module.

    > We might need to look at the com.ibm.ws.security.*=trace to see what might be going wrong here.

    Well, that could be an option indeed. I did get some data that might be helpful here already. After some digging in debug mode and by stepping into the code and inspecting the variables, I discovered the following. The issue seems to be primarily with the com.ibm.ws.security.web.JaspiCallbackHandler. Upon calling its handle method, there is at some point a call to a method named handleCallerPrincipalCallback and then to addUniqueIdAndGroupsForUser. This then does a call to registry.isValidUser, which I suspect is the culprit.

    If I enter a the name of a user that I added to WebSphere, the above mentioned registry.isValidUser returns true, and two entries will be set by the handler: "com.ibm.wsspi.security.cred.uniqueId" and "com.ibm.wsspi.security.cred.groups". If the handle method now returns, clientSubject.privCredentials will contain the following entries:

    com.ibm.wsspi.security.cred.uniqueId=user:defaultWIMFileBasedRealm/uid=test,o=defaultWIMFileBasedRealm
    com.ibm.wsspi.security.cred.securityName=test
    com.ibm.wsspi.security.cred.groups=[]

    Now if I pass the name of a user that I did not add to WebSphere, say "testnotinwebsphere" to the CallerPrincipalCallback then clientSubject.privCredentials will only contain the following entry after the handle call:

    com.ibm.wsspi.security.cred.securityName=testnotinwebsphere

    If you would like to test this for yourself, the full test code is as described here: http://arjan-tijms.blogspot.com/2012/11/implementing-container-authentication.html and it can be downloaded directly from https://code.google.com/p/javaee6-auth-example/source/browse
    Thanks for the analysis. Can you please open a problem report with IBM so that our service team will look at this in detail and provide a response/fix?

    --Ajay