1 2 Previous Next 17 Replies Latest reply: Sep 26, 2010 7:04 PM by Simon Kissane-Oracle Go to original post RSS
      • 15. Re: Security Violation: User: '<anonymous>' has insufficient permission....
        user567398
        Hi,
        I am also facing the same problem as Security Violation for EJB method call when i am trying to change the password for first time user login time.

        160]Security Violation: User: 'testuser001' has insufficient permission to access EJB: type=<ejb>, application=Xellerate, module=xlDataObjectBeans.jar, ejb=tcUserOperations, method=changePasswordforSelf, methodInterface=Remote, signature={java.lang.String,java.lang.String,java.lang.String}.
        Thor.API.Exceptions.tcAPIException: [EJB:010160]Security Violation: User: 'testuser001' has insufficient permission to access EJB: type=<ejb>, application=Xellerate, module=xlDataObjectBeans.jar, ejb=tcUserOperations, method=changePasswordforSelf, methodInterface=Remote, signature={java.lang.String,java.lang.String,java.lang.String}.


        I have installed the OIM 91.0.1 on Weblogic 1013 cluster environment. OIM deployed on Weblogic Admin server.

        when i am doing any operation with 'xelsysadm' working fine but if i do any operation with newly self created users then thsi issue raising.

        I have followed to apply all the suggestions in this thread but not working to me. Basically i dont want the security at this time.

        create Anonymous , UNKNOWN users and associated to Administrators group also, internal user associated to Administrators group in weblogic default realm and restarted all the servers. Still getting the same problem.
        *Note: this OIM deployment is very basic installation and no customizations done at. Everything working perfect with xelsysadm but self service operations are not working with newly created users .


        Appreciated if any one have solution.
        • 16. Re: Security Violation: User: '<anonymous>' has insufficient permission........
          703604
          I am getting the same error as yours.

          Scenario: The User Registration process has a task where the assignee is selected by a task assisgnment adapter. For the first request after compile the adapter, it works very well, but the error happens when I do the second request. IN the request fields I got the Manager Login and (adapter uses OIM APIs) search his users.key and set the result to the adapter return for key.

          For the second request, I saw OIM had run the adapter four times. *[Update]* Every adapter has a calll to finalizeAdapter() and I think this call is destroying the login context that has to be propagated for the next call (but is been destroyed in the finalizeAdapters() before finish the first call, I suppose). The authwl.conf is configured with weblogic.security.auth.login.UsernamePasswordLoginModule, so it is using the WebLogic's LoginModule for authentication based on the username and password: user Internal, for example. For the java.security.auth.login.config property, the startup script is configure with authwl.conf. In the Self-Register the user is not authenticated so only God knows what OIM does behind the scene to propagate the login :-)

          I haven't change security configuration in my weblogic (not clustered): configuration default of OIM with Internal user and JNDI security policy is group: everyone. That means no restrictions, right? I added a policy conditions for all methods: Allow Access to everyone, but the problem still persists...

          Any idea? I've spent two days on it...

          Solution: In my case... I have an API that uses DatabaseReference as a constructor's parameter and the API makes all calls using this references... For the methods I am using in the User Registration process, they create an instance of tcUtilityFactory using the constructor that accepts jndiProperties, username and password.

          Conclusion: My problem was not becuase I was using DatabaseReference. The problem was: The database reference was passed as a constructor parameter and it is stored in a member variable. Now all methods that are used by the adapters of User Registration process have a tcDataProvider paramater (argument is Adapter database reference) as the example below. In summary, I cannot have those variables declared as a member variable because they will be destroyed at any moment.

               public static String getRequestAttribute(long requestKey, String attributeName, tcDataProvider tcProvider) {
                    String attributeValue = JavaTaskBase.VALUE_NOT_FOUND;
                    try {

          tcRequestOperationsIntf requestOp = (tcRequestOperationsIntf)tcUtilityFactory.getUtility(tcProvider, JavaTaskBase.REQUEST_OPERATIONS_API_NAME);

                         tcResultSet resultSet = requestOp.getRegistrationUserDetails(requestKey);
                         int qtyRows = resultSet.getTotalRowCount();

                         for (int j = 0; j < qtyRows; j++) {
                              resultSet.goToRow(j);
                              String columnName = resultSet.getStringValue(JavaTaskBase.REGISTRATION_ATTRIBUTE_NAME);

                              if (columnName.equals(attributeName)) {
                                   attributeValue = resultSet.getStringValue(JavaTaskBase.REGISTRATION_ATTRIBUTE_VALUE);
                                   break;
                              }
                         }
                    } catch (Exception ex) {
                         System.out.println("############## Exception in getRequestAttribute ###############");
                         ex.printStackTrace();
                         System.out.println("#############################");
                         attributeValue = JavaTaskBase.EXECUTION_ERROR;
                    }

                    return attributeValue;
               }


          Thanks,

          Edited by: Renato.Guimaraes on 03/09/2009 14:13 - information about my weblogic and OIM

          Edited by: Renato.Guimaraes on 03/09/2009 14:40 - I added policy condition: allow access to everyone

          Edited by: Renato.Guimaraes on 04/09/2009 05:25 - Updated my suspicion

          Edited by: Renato.Guimaraes on 04/09/2009 06:52 - Solution

          Edited by: Renato.Guimaraes on 04/09/2009 08:58 - I promise it is my last update. :-) [Conclusion]
          • 17. Re: Security Violation: User: '<anonymous>' has insufficient permission........
            Simon Kissane-Oracle
            Hi everyone

            There are a couple of different issues that could be happening here:
            1) You get this when an OIM API is being called, by your custom code, or by OOTB OIM code (web interface, scheduled task, design console, etc.) -- this indicates a problem with your security setup, e.g. missing User group, missing Internal user, Internal not a member of User, etc.
            Try My Oracle Support Note 1147967.1 , Note 1159863.1

            2) You get this when the Java finalization thread is performing finalization on objects being garbage collected. You will get a stack trace like this:
            ERROR,12 Aug 2010 11:39:35,889,[XELLERATE.JAVACLIENT:error],Class/Method: tcDataBaseClient/getInterface encounter some problems: [EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB: type=<ejb>, application=Xellerate, module=xlDataObjectBeans.jar, ejb=tcDataBase, method=isOpen, methodInterface=Remote, signature={}.
            java.rmi.AccessException: [EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB: type=<ejb>, application=Xellerate, module=xlDataObjectBeans.jar, ejb=tcDataBase, method=isOpen, methodInterface=Remote, signature={}.
                 at weblogic.ejb.container.internal.MethodDescriptor.checkMethodPermissionsRemote(MethodDescriptor.java:560)
                 at weblogic.ejb.container.internal.BaseRemoteObject.checkMethodPermissions(BaseRemoteObject.java:115)
                 at weblogic.ejb.container.internal.BaseRemoteObject.preInvoke(BaseRemoteObject.java:272)
                 at weblogic.ejb.container.internal.StatefulRemoteObject.preInvoke(StatefulRemoteObject.java:57)
                 at com.thortech.xl.ejb.beans.tcDataBase_vhi04i_EOImpl.isOpen(tcDataBase_vhi04i_EOImpl.java:253)
                 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                 at java.lang.reflect.Method.invoke(Method.java:597)
                 at Thor.API.Base.SecurityInvocationHandler$1.run(Unknown Source)
                 at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
                 at weblogic.security.service.SecurityManager.runAs(Unknown Source)
                 at weblogic.security.Security.runAs(Security.java:41)
                 at Thor.API.Security.LoginHandler.weblogicLoginSession.runAs(Unknown Source)
                 at Thor.API.Base.SecurityInvocationHandler.invoke(Unknown Source)
                 at $Proxy59.isOpen(Unknown Source)
                 at com.thortech.xl.client.dataobj.tcDataBaseClient.getInterface(Unknown Source)
                 at com.thortech.xl.dataaccess.tcDataBaseClient.close(Unknown Source)
                 at com.thortech.xl.server.tcDataBaseClient.close(Unknown Source)
                 at com.thortech.xl.server.tcDataBaseClient.finalize(Unknown Source)
                 at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
                 at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
                 at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
                 at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
            Notice the "java.lang.ref.Finalizer$FinalizerThread.run" at the bottom of the stack. Also, if you change your Log4J config to output thread names in log files (%t), you will notice a thread name of "Finalizer" or similar (name may vary depending on which JVM you use).

            Now, the root cause of this type of error is some kind of connection leak. The most common cause is your custom code not closing all OIM API objects it uses (tcUtilityFactory, tcUserOperationsIntf, etc.). So, the garbage collector will later try to close the API object, and get this error. You can see in the stack which object it is trying to close (in this case, tcDataBaseClient.) So, study your custom code, find where you are not calling close().

            Also, these leaks can be made, not just in terms of these errors. They can also be consuming memory, database connections, etc.

            It is also possible that the leak is actually in our OOTB code, not in your custom code. However, in my personal experience, it is more commonly the custom code that causes the problem than the OOTB code from Oracle.

            A couple of more points:
            1) The suggestion to secure the JNDI namespace may well stop this error from occurring. But it doesn't actually fix the leak. I suspect, if it makes the errors go away, it must be giving the finalizer thread the necessary principal to call the close() method successfully. So, the leak is still happening, but the finalizer is successfully cleaning things up now. Which might make the consequences of the leak better (e.g. the finalizer might now be freeing some resources it couldn't before), but the leak itself is still there.
            2) Someone above suggested adding user "anonymous" to the "System Administrators" group. DO NOT DO THIS! By doing this, you are saying effectively that an unauthenticated user has system administrator privilege. Yes, you will make this error go away, but you are potentially introducing a massive security hole into your system in the process.

            If you need further help, please log an SR.

            Hope this helps
            Simon Kissane
            Oracle Support
            1 2 Previous Next