Re: NullPointerException while performing authorization - Websphere

This is a discussion on Re: NullPointerException while performing authorization - Websphere ; Sounds like your implementation of this provider is not returning the expected values to WebSphere per the interface. Thus you're causing WebSphere to receive a null object where it is not expecting one.. Interestingly enough, if you find this to ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: NullPointerException while performing authorization

  1. Re: NullPointerException while performing authorization

    Sounds like your implementation of this provider is not returning the expected values to WebSphere per the interface. Thus you're causing WebSphere to receive a null object where it is not expecting one..



    Interestingly enough, if you find this to be the case, regardless of if some specification says that you're not allowed to present a null value as a return object, WebSphere code should always check a return value for null before attempting to use it and I'd open a PMR with your code samples in an attempt to raise an APAR to strengthen the code around this area to be more robust.



    John Pape

    WebSphere Advisory Software Engineer

  2. Re: NullPointerException while performing authorization

    Sharon, John appreciate your feedback. I'm not exactly sure what could be wrong with the provider implementation. As per WAS docs, the following are the steps in the authorization process when JACC is enabled.



    Access decisions for enterprise beans

    When security is enabled, and an EJB method is accessed, the EJB container delegates the authorization check to the security runtime. If JACC is enabled, the security runtime uses the following process to perform the authorization check:



    1. Creates the EJBMethodPermission object using the bean name, method name, interface name, and the method signature.

    2. Creates the context ID and sets it on the thread by using the PolicyContext.setContextID(contextID) method.

    3. Registers the required policy context handlers, including the Subject policy context handler.

    4. Creates the ProtectionDomain object with principal in the Subject. If no principal exists, null is passed for the principal name.

    5. The access decision is delegated to the JACC provider by calling the implies method of the Policy object, which is implemented by the provider. The EJBMethodPermission and the ProtectionDomain objects are passed to this method.

    6. The isCallerInRole access check also follows the same process, except that an EJBRoleRefPermission object is created instead of an EJBMethodPermission object.







    In my JACC implementation, step 5 works fine when the implies method returns true to indicate a successful authorization (it's a boolean true or false value, no chance of returning a null value here). Only when the implies method returns false, the NullPointerException is thrown instead of some more appropriate exception that can be specifically handled by the application to indicate an authorization failure. Except for this issue, the JACC provider integration functions flawlessly.



    Irrespective of the exact cause of this error, I agree with John that WAS should be more robust in handling such Null scenarios.



    Thanks.

+ Reply to Thread