Write for OTN
Earn money and promote your technical skills by writing a technical article for Oracle Technology Network.
Learn more
Stay Connected
OTN Architect Community
OTN ArchBeat Blog Facebook Twitter YouTube Podcast Icon

Programmatic Identity Assertion with Oracle Platform Security Services (OPSS)

Shailesh K. Mishra

Using Oracle Platform Security Services APIs to perform programmatic identity assertion

December 2013

Introduction

Identity assertion is a process of establishing an identity without its secret credential (e.g., performing an authentication decision based on user name only, without the corresponding password). Why do we need such a mechanism? Consider the example of an application that places a Java Message Service (JMS) message on behalf of a logged-in user. A second application takes this message for processing. Now the question is: in which security context should this second application process this message? There are three possible options: anonymous, a service account user (which is always a fixed user account, irrespective of which logged-in user sends the message), or a user who places the message. The first option is obvious. The second can be achieved using message-driven beans and a "runAs" role. This article provides a solution for the third option.

This article assumes that the reader has good understanding of Java Authentication and Authorization Service (JAAS) and Oracle Platform Security Services (OPSS) APIs.

Performing Identity Assertion using OPSS API

Let's continue with our example, above. To achieve the third option, we need to create an authenticated subject for the user who placed the message in the JMS queue. To create an authenticated subject, typically we need the user name and password. While the first application code can propagate the user name—it can be retrieved from current running JAAS subject—by placing it in the message, it does not have a password. To create an authenticated subject, we will have to assert the identity for this user. The following section talks about how this can be achieved using OPPS API.

OPSS SubjectSecurity and ActionExecutor API

SubjectSecurity class provides the getActionExecutor method, which takes the user name as a parameter. Its implementation: first, assert the specified user name against the identity store and create an ActionExecutor for the asserted user. ActionExecutor has the execute method, which takes java.security.PrivilegedAction or java.security.PrivilegedExceptionAction as a parameter. The code inside the run method of PrivilegedAction/ PrivilegedExceptionAction runs under the security context of the asserted user. Please consult the following ActionExecutor Java documentation:

"Only the application logic that runs in PrivilegedAction or PrivilegedExceptionAction is associated with the user's platform security context automatically by ActionExecutor, in case of Weblogic server, it's associated with WLS subject by invoking Security.runAs(Subject, PrivilegedAction). As such, application operations required platform security will be handled by the platform security context implicitly, e.g. EJB invocation and secure resource access." (sic)

The getActionExecutor method of SubjectSecurity class is protected by code permission oracle.security.jps.JpsPermission with the name "IdentityAssertion" and action "execute". The calling code sources need to be granted the above permission before it can call this method.

Please refer to the references section for more detail on SubjectSecurity and ActionExecutor APIs.

Gluing it all together

Continuing with our example, to achieve the third option, the second application must create an ActionExecutor for the user who put the message in the JMS queue and run the message-processing logic in its execute method as shown below:

/*
 * OPSS API SubjectSecurity.getInstance().getActionExecutor(this.username) is protected by 
 * code permission oracle.security.jps.JpsPermission with name "IdentityAssertion" and action
 * "execute". The application code sources need to be granted the above permission when 
 * invoking this method. Wrapping this call in AccessController.doPrivileged to avoid all 
 * upper stack codes to have this permission.
 */
   try{    
     ActionExecutor  ae = AccessController.doPrivileged(new PrivilegedExceptionAction
	 <ActionExecutor>() {
                public ActionExecutor run() throws Exception{
                    try {
                        return  SubjectSecurity.getInstance().getActionExecutor(username);
                    } catch (JpsException e) {
                       //handle exception
                    } catch (AssertionException e) {
                     //handle exception
                    }
                }
            });
        //execute your business logic that needs to run under security context of given user.
        ae.execute(new PrivilegedExceptionAction<Object>() {
                public Object run() throws Exception{
                    //run your code here
                }
            });
        }catch(Exception e){
          e.printStackTrace();
        }

Granting code source permission

Run the following wlst command to seed needed permission to use getActionExecutor method of SubjectSecurity API. For more details on OPSS-related wlst commands, please refer to the references section.

grantPermission(codeBaseURL=""url of your code source>", 
permClass="oracle.security.jps.JpsPermission", permTarget="IdentityAssertion",
permAction="execute")

Conclusion

This article shows how programmatic identity assertion can be performed using OPSS APIs in cases where code must run under the security context of a runtime identity.

References

About the Author

Shailesh K. Mishra is part of the Oracle Identity Manager team. He earned his B. Tech. from IIT BHU, and enjoys exploring middleware performance and security in his free time.