Securing Oracle* Fusion Middleware with Microsoft* Active Directory

Many enterprises have invested in Oracle* Fusion Middleware for their SOA implementations, sometimes along with other SOA enabled applications such as Web 2.0, Content Management, Business Process Management, etc. As applications are born from this stack of software you start to realize (or further realize) the importance of the total management lifecycle for this new type of application suite. These demands can grow significantly, especially if you've attemped to deliver many at once, often called 'Big Bang SOA'. Certain facets may have been made more clear by initial steps in the delivery of applications early in the maturity level. Often there is some realization around Identity Management in particular as part of the overall development pattern for giving context to Web 2.0 and BPM activities. Further rationalizing how the Identity Management ecosystem may need to be enhanced and provided as a more integral part of enterprise SOA can be disruptive. In addition, how the initial SOA may have been delivered (systems integrator, professional services, etc) can also be misleading for this next iteration of SOA with more Identity Management integration, capabilities and perhaps products. This is to say that generally the Identity Management ecosystem will more than likely be owned and operated by the customer as a mission critical asset. Undertaking coordination amogst these parties of what to deliver for Identity Management in this new paradigm to the point of exhibiting competence in such a critical, risk oriented area, can take time.

This blog posting is about how to leverage an existing Identity Management asset such as Microsoft* Active Directory along with Intel® SOA Expressway in order to bring authentication and authorization to your Oracle* Fusion Middleware SOA implementation. This isn't to say that there isn't tremendous value in the Oracle* Identity Management suite of products or that what we're presenting here will obviate the need for a more robust Identity Management capability. That takes time to digest to the point of being able to implement, operate and manage in the scope of a larger enterprise SOA. Since there is standards based integration to all of Oracle* Fusion Middleware we will blog about many facets of leveraging Intel's SOA Expressway, a web services security gateway, in order to expose business services along with identity platform services for secure delivery. In this case we will show a few simple Microsoft* Active Directory Organizations and Groups that allow you to protect a BPEL Process with not only authentication but role and attribute based authorization. In the future we will also look at the third 'A' after Authentication and Authorization which is that of Accounting (or Audit) which is a critical part of enabling integrated governance.

Let's first have a look at our simple synchronous BPEL Process in Oracle* JDeveloper:



This BPEL process will make a call to the HR sample schema in an Oracle* Database. It will do so with the name of a Region from the Employee Details View in that schema:



Here are the input and output XSD types of the BPEL process itself which reflect the SQL query parameter as well as the return type from the database query:



Make sure you have deployed a JDBC configuration to Oracle* WebLogic that supports your JNDI name for the HR database lookup in your BPEL process. Here is a good blog on how to set up this item (using the first ~6 screen shots in the WebLogic Administration Console as a reference).

Now let's expose this Oracle* Fusion Middleware BPEL Process in our service gateway. Save the WSDL from the location shown in Oracle* Fusion Middleware Enterprise Manager (on the 'Test' tab of the deployed BPEL Process):



You will also need to update the reference to HR_Table.xsd in the WSDL (delete the highlighted text) and make sure that file is available along with the WSDL from your BPEL process:



In Intel SOAE Expressway Services Designer we will begin a project of type 'Service Proxy':



Now we can use the WSDL from our BPEL process to define what is to be proxied:



Then we'll use HTTP Basic Authentication with LDAP:



Before we get into our use case to tie these items together here is a screen shot of my Microsoft* Active Directory configuration with another tool next to it called JExplorer which can be handy for exploring the LDAP Directory Information Tree. It is very important to understand these basic LDAP types as Microsoft* Active Directory is based on LDAP (and referred to as LDAP from hereon since this could be any LDAP server as far as Intel SOA Expressway is concerned). The groups here are from data in the HR schema from the Oracle* Database:



Let's now update the ldap_auth.aaa (Authenticate, Authorize, Audit) object with the details needed to Authenticate to LDAP. We'll do that on the Identity Management tab of the ldap_auth.aaa object. I've created a user named 'Peter Hall' in LDAP and made him a member of Region->Europe and the Department->Human Resources group:



then Authorize access to the SOAE_HR service which we'll do on the Resource Authorization tab of the ldap_auth.aaa object:



We will use the variable %extracted-identity here to determine membership in the Human Resources group in
LDAP. You can use the same query in JExplorer to test that your LDAP will provide a return value. Once we're done with that we'll save the ldap_auth.aaa object and compile our project in Intel SOA Expressway Services Designer by exporting a bundle we can load onto the SOA Expressway runtime. We do this by navigating to Intel SOA Expressway->Export Application Bundle after right clicking on our project in Eclipse. At this time a dialogue box is presented:



This is telling us that we haven't yet generated our BPEL workflow for Intel SOA Expressway and clicking OK will do so automatically. Once done we now have our BPEL model that performs the service proxy functionality described in the ldap_auth.aaa object along with WSDL that we imported from our BPEL HR service:



We also have an export bundle that we can load into the Intel SOA Expressway runtime to test:



The important thing to do before making this Application active is to store the LDAP hostname and credential that will be used to bind to LDAP when executing the AAA step in our service proxy workflow. We start by editing the 'Invocation Agent' that will make the AAA calls to LDAP:



And entering our credential for the LDAP bind:



Now we will use the WSDL generated in our Intel SOA Expressway Services Designer to create a request in a SOAP testing tool like SOAPUI. We will need to provide our username and password, in my case it's peterhall and Password1, as a Base64 encoded variable in an HTTP Header called Authorization. Take your username:password and convert it with a tool such as this and put the string 'Basic ' in front of the result as seen here. You will also need to change the endpoint hostname in SOAPUI from the Oracle* BPEL Server referenced in the WSDL to the hostname for Intel SOA Expressway:



While this proxied request should succeed if everything is done correctly we haven't confirmed that Peter Hall, who says he is an authorized requestor of Human Resources data for Europe, should actually receive that data. In order to do that we'll create another AAA object in our project and utilize it for querying another branch in our LDAP for membership in the Region that was passed to the request. First we need to delete the template object that was generated from the original project so it doesn't try to regenerate existing workflows. You could continue to add security steps to the template to make the project creation of security workflow assets more automated but it is easier to watch the development process initially to gain understanding of what's being generated:



Now we'll open the BPEL process created for us in the previous steps and drag another AAA action from the Security palette to the right onto the BPEL workflow after our first AAA step. Finally select the new AAA object in the workflow by a single left click and in the bottom 'Properties' tab is a link to 'Create New Policy'. Accept the defaults and change the names to be more descriptive:




Now let's finish this up by Authorizing access to this particular set of HR data from the BPEL HR service by validating the Region attribute value passed in from the client request. We will continue to use %extracted-identity from the HTTP Basic Authentication for the LDAP query intersection with the Region OU:



We'll also add an 'If' control loop that compares the value returned from our LDAP query with that provided by the user:



In this simple case a user belongs to one and only one Region but there are logic constructs in BPEL to handle XML repeating groups converted to and from comma seperated lists. Here is our XSLT/XPath comparison for the 'If' control that will simply exit if the user has submitted a Region other than the one they belong to. In a production system we would generate a more meaningful message for error handling:

substring(substring-before(string($AAA3_InternalSecurityMetadata/soae-ab:aaaLDAPAuthorizationResponse/ldap:ExternLookupResponse/ldap:batchResponse/ldap:searchResponse/ldap:searchResultEntry/@dn),','),4,20)=string($Receive/soapenv:Body/hr:HRSelect_regionInputParameters/hr:region)

Once we've saved and re-deployed our application bundle we are now not only providing a means for the client to provide data about their Region to the service but also using LDAP search to Authorize that the authenticated user can see that data.

In this blog we've exposed the Identity Management functions necessary to Authenticate and Authorize our Oracle* Fusion Middleware BPEL HR service with LDAP and we've done so in a programmitic way that mimics the kinds of tasks developers perform for the creation of business logic. This enables a simpler, business oriented middleware stack while also enabling SOA developers to control the way their applications are secured at the edge of the network and providing enterprise architects ability to enforce how these policies are applied.

This is only a rudimentary use case here in terms of simple business rules and Oracle* Fusion Middleware itself, in fact one that could be performed with the ESB/Service Mediation capabilities of Intel SOA Expressway. However, this was to lay a foundation for the next blog posting on this subject where we will look at enabling the Oracle* BPEL Process Manager Human Workflow web services with SAML assertions on the Intel SOA Expressway service gateway in order to present stateful data persisted in the scope of business transactions with asynchronous services. Also between the template creation of the Intel SOA Expressway Services Designer project as well as the creation of the export bundle that serves as an archive of designtime and runtime we've uncovered some interesting possibilties that we will address in a future blog on service development lifecycle including configuration management.

To wrap up there are a number of challenges that await, impact somewhat unknown, in the scope of an SOA as it goes beyond the intial maturity spiral or recovers from a 'Big Bang' SOA that experienced varying degrees of success for adoption across the enterprise. One of those challenges that will indeed permeate the entire SOA lifecycle is that of Identity Management. The major enterprise application vendors (and smaller ones as well) have a wealth of tools for implementing a robust Identity Management strategy. However, factoring these products into an SOA that is attempting to move to the next level of maturity for offering services across an organization and potentially to the outside world as well, can be an arduous, potentially lengthy undertaking for a myriad of reasons. One of the most conspicuous of these reasons is how a set of common operation procedures will be reached that satisfies the risk inherent with managing identities that will have access to critical information systems such as those based on Oracle* Fusion Middleware. Since middleware suites like Oracle's are based largely on SOA there is a safe and easy way to expose these services to a larger audience as you realize the appetite for a broader Identity Management infrastructure over time. That way is Intel SOA Expressway which can not only leverage your existing enterprise Identity Management infrasructure like LDAP for authentication and authorization of Oracle* Fusion Middleware services but also offer a service oriented development patterned environment for these Identity Management operations that will become such a critical part of your enterprise SOA as you reach new levels of maturity.

If you'd like to sign up for an evaluation of SOA Expressway as a download or online you can do so here.

*Other names and brands may be claimed as the property of others.









Per informazioni più dettagliate sulle ottimizzazioni basate su compilatore, vedere il nostro Avviso sull'ottimizzazione.