4

I have a JASPIC auth module that works really well on GlassFish, WildFly and WebLogic.

Now we have a new customer who uses WebSphere 8.5, and I can't get the auth module to run properly there.

The problem is that WebSphere doesn't accept the username that the auth module puts in the CallerPrincipalCallback. Our other supported servers just accept this, but WebSphere for some reason thinks it needs to perform some extra checks.

After investigating the issue I stumbled upon this one: https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014937852

This exactly describes my problem, but there's no solution given there.

How can I confince WebSphere to just process the CallerPrincipalHandler and accepting any username like all other servers do?

Mike Braun
  • 3,729
  • 17
  • 15
  • 1
    Mike, it might be an issue. You should consider opening PMR in IBM Support to clarify that. – Gas Jan 15 '15 at 10:26

2 Answers2

5

The behavior attributed to WebSphere 8.5, WRT the processing of the JASPIC CallerPrincipalCallback is NOT compatible with the JASPIC specification.

The CallerPrincipalCallback(s) must be able to support the case where the user registry is integrated within the SAM, including for the purpose of providing user group memberships.

For the special case of password based validation, A SAM can invoke the container provided CallbackHandler to handle a PasswordValidationCallback; in which case the CallbackHandler will return a failure result if the username and/or password combination does not exist in the user registry integrated with the container's CallbackHandler. In that case, the SAM would return a failed (or continuation) authentication result and would NOT invoke the CallbackHandler to handle the CallerPrincipalCallback.

HTH,

Ron Monzillo

monzillo
  • 51
  • 1
1

In general I usually advise to use container authentication/authorization, if possible, as it is already provided by server infrastructure and for majority of cases sufficient.

However, if in your case you need it, here are some hints.

If you want to avoid extra checks, and allow authentication of users that are not in the WebSphere user registry you have to create full subject like this (this is fixed user simplification), instead of using callbacks:

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

   String uniqueid = "test";
   String username = "test";
   String password = "test";

   Hashtable hashtable = new Hashtable();
   hashtable.put(AttributeNameConstants.WSCREDENTIAL_UNIQUEID, uniqueid);
   hashtable.put(AttributeNameConstants.WSCREDENTIAL_SECURITYNAME, username);
   hashtable.put(AttributeNameConstants.WSCREDENTIAL_PASSWORD, password);
   List groups = new ArrayList();

   // if you want to use existing group uncomment this
   // com.ibm.websphere.security.UserRegistry reg = 
   //  (com.ibm.websphere.security.UserRegistry) ctx.lookup("UserRegistry");    
   // String groupID reg.getUniqueGroupId("testers");
   // groups.add(groupID); // for federated registry it returns cn=testers,o=defaultWIMFileBasedRealm


   // if you want to use fake groups just add them here, and provide correct binding file - see below. If you don't want to use groups just omit WSCREDENTIAL_GROUPS  
   groups.add("testers");

   hashtable.put(AttributeNameConstants.WSCREDENTIAL_GROUPS, groups); //optional 
   hashtable.put(AttributeNameConstants.WSCREDENTIAL_CACHE_KEY, "myCustomAttribute" + uniqueid);
   clientSubject.getPrivateCredentials().add(hashtable);

   return AuthStatus.SUCCESS;

}

I'm assuming that you want to map these users to some security roles in your application. You can map it either using users, groups or special subject. You need to have roles defined in your application.xml, like this:

<security-role>
    <role-name>user</role-name>
</security-role>

and you will need binding file, since binding cannot be done via console for non-existing users/groups. Create ibm-application-bnd.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<application-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-application-bnd_1_2.xsd"
version="1.2">

  <security-role name="user">
    <user name="test" access-id="user:defaultWIMFileBasedRealm/test"/>
    <group name="testers" access-id="group:defaultWIMFileBasedRealm/testers"/>
    <special-subject type="ALL_AUTHENTICATED_USERS" />
  </security-role>
</application-bnd>

I provided sample for all kinds of mappings, use the one that suits your needs:

  • user - for mapping named users to role
  • group - for mapping group to role
  • special-subject - if you want any successfully authenticated user to have that role.

Important if you want to use fake users/groups you have to provide access-id attribute, if they are in the registry then just provide name.

See also:

Gas
  • 17,601
  • 4
  • 46
  • 93
  • 1
    Thanks a lot for the answer. Fyi, JASPIC -is- container authentication. I'll try the hashtable, but I hate to have special code for WebSphere in my SAM. Why isnt't WebSphere fully EE 6 compatible here? – Mike Braun Jan 01 '15 at 07:46
  • 2
    Ps "instead of using callbacks" is more than a bit problematic, as the same SAM has to be used for multiple servers :( – Mike Braun Jan 01 '15 at 08:00
  • @MikeBraun WebSphere is fully Java EE 6 compatible, it provides JASPIC API. However integration with server security internals is always server specific, and there is no guarantee that same code will work for different vendors. I'd suggest to to create SAM per server, and instantiate correct one based on properties. – Gas Jan 01 '15 at 11:13
  • 3
    @Gas I don't think your last comment is entirely correct. The entire purpose of JASPIC is that the same code will work for different vendors. The JASPIC spec gives exactly that guarantee, and WebSphere doesn't seem to implement it correctly. It *must* be able to process the handler in a compatible way and by requiring an alternative method it doesn't do that. But the JASPIC TCK is very small, so this case was probably missed. p.s. I was the one who originally reported the issue at the IBM forum mentioned in the OP, but I didn't follow up on it. My bad. – Arjan Tijms Jan 01 '15 at 20:53
  • @MikeBraun Regarding callbacks - if you have users, you usually want to store them in some kind of registry. WebSphere provides plugins for some common registries (like LDAP, local OS, file, proprietary database), but if none fits your needs WebSphere provides also custom option, where you can implement whatever you need. **If you would implement custom registry and configure it for server serving your application, then users would be found and callbacks would work**. – Gas Jan 01 '15 at 23:18
  • 1
    @Gas sorry if I didn't make my case clear. The users are fully under our own control and are not in a common registry. You recommend going for a WebSphere specific custom registry, but JASPIC already is that for the container. We don't want to implement something specific for each server, but use one that works everywhere. Our JASPIC module works on every compatible EE 6 server we tried, *except* WebSphere. Surely the issue has to be with WebSphere then? – Mike Braun Jan 02 '15 at 11:05
  • 1
    @Gas See the answer by JASPIC spec lead Ron Monzillo. WebSphere is really not spec compliant here. – Arjan Tijms Jan 02 '15 at 21:04
  • 1
    @ArjanTijms Yes, I see it. I'll try to find out some more about this. Thanks for all your comments. I just wrote my suggestions how I was able to make it work for now. – Gas Jan 02 '15 at 21:31
  • @Gas you're welcome, looking forward to hear about what you can find out about this. In the meantime I'll try to report the issue as originally being asked at the forum. Thanks! – Arjan Tijms Jan 02 '15 at 21:34
  • @MikeBraun As a workaround, if you fully control your users, you could create custom user registry for WAS. It shouldn't be a big problem, and then your callbacks should work without WebSphere specific code. – Gas Jan 03 '15 at 00:26
  • 1
    @Gas FYI, I just did a quick test of JASPIC in the march EE 7 beta of Liberty, and the exact same problem is still there. What would be the best place to report this and/or work with the engineers at IBM to get this fixed? – Arjan Tijms Apr 07 '15 at 22:35
  • @ArjanTijms For Liberty the best place would be to post it on the [dwAnswers](https://developer.ibm.com/answers/smart-spaces/24/wasdev.html). It is monitored by Liberty developers, so you may have some answer there. Did you have time to report PMR with the original isuue? – Gas Apr 07 '15 at 22:59
  • @Gas It's perhaps not so much a matter of asking a question, since I pretty much confirmed that the JASPIC 1.1 feature in Liberty is likely not entirely spec compliant. Do you have a link to an issue tracker where I can report this? I searched around and found http://www.ibm.com/software/support/probsub.html is that the right location for the PMR report? – Arjan Tijms Apr 08 '15 at 07:18
  • @ArjanTijms Check this http://www-01.ibm.com/support/docview.wss?uid=swg21507639 , but for Liberty you might have quicker response posting it here https://developer.ibm.com/answers/smart-spaces/24/wasdev.html – Gas Apr 10 '15 at 12:39
  • @ArjanTijms Could you please try the latest - april/may beta, there where some fixes regarding this. – Gas Apr 16 '15 at 21:50
  • 1
    @Gas just did, but it's the same issue (I tried `wlp-beta-javaee7-2015.4.0.0.zip`). I've just developed a noop user registry for it, and then it works (will publish a blog article about this soon), but that's of course not really portable and a real pain to get into the Java EE 7 samples project. On the bright side, I saw that the EE 7 samples project is already on the radar of one of your colleagues: https://github.com/javaee-samples/javaee7-samples/issues/263 So I'm sure we'll be able to resolve this eventually ;) Thanks for the update! – Arjan Tijms Apr 17 '15 at 11:38
  • I get the following error on 8.5.5.11 `WebCollaborat A SECJ0056E: Authentication failed for reason ` Looking further I saw the following while debugging com.ibm.websphere.security.auth.WSLoginFailedException: JASPI custom login cannot be performed, Subject does not have Hashtable with custom credentials. – Archimedes Trajano Jul 07 '17 at 17:38