All,
December 31,2010 is my last day at Oracle. This blog has been a really amazing experience for me, and truly one of the most interesting and rewarding parts of my job at Oracle during the past three years. It represents a significant amount of work to build consistent quality technical content, and actively work with customers on solving their most challenging problems. Thank you for everyone who has made this blog such a success.
But wait....the blog will continue on. Brian and Chris are redoubling their efforts to continue what we started on into the coming year.
I've started a new blog at http://xmlgateway.blogspot.com. I hope that you'll check it out.
Thanks, Good Luck and Happy New Year,
Josh
Thursday, December 30, 2010
Wednesday, December 22, 2010
Creating OES SM instances on 64 bit systems
I've already opened a bug on this against OES 10gR3 CP5, but in case anyone else runs into it before it gets fixed I wanted to blog it too. (NOTE: CP5 is when official support was introduced for running OES on a 64 bit system with a 64 bit JVM)
When you run the ConfigTool on a 64 bit Linux host you may see an error like this:
As you can see the first error is that the instancewizard failed. THAT problem is probably occurring on your system because when you applied the CP you chose a 64 bit JVM but the instancewizard.sh script has a hard coded JAVA_HOME pointing to a 32 bit JVM. When the instance wizard runs (under the covers) the JVM is trying to load a 64 bit JNI library that the CP installed.
The fix?
Edit instancewizard.sh and change JAVA_HOME to point to the right JVM. Like so:
Incidentally I found the root cause by running instancewizard.sh with the -log= and -log_priority= flags. You can run ./instancewazard.sh -h to get the command line help.
When you run the ConfigTool on a 64 bit Linux host you may see an error like this:
Check completed succesfully. Starting to make changes ... Creating SSM instance... 2010-12-22 14:36:46,952 [Main Thread] ERROR com.bea.security.SsmConfigTool.AlesConfig - Instance wizard returned error: 255 Done creating SSM instance. Loading ALES Policy using policyloader. Please wait ... 2010-12-22 14:36:46,956 [/software/oracle/middleware/ales32-ssm/wls-ssm/instance/irmssm/bin/policyloader.sh] ERROR com.bea.security.SsmConfigTool.Daemon - Error During execution of requestd command java.io.IOException: java.io.IOException: /software/oracle/middleware/ales32-ssm/wls-ssm/instance/irmssm/bin/policyloader.sh: not found
As you can see the first error is that the instancewizard failed. THAT problem is probably occurring on your system because when you applied the CP you chose a 64 bit JVM but the instancewizard.sh script has a hard coded JAVA_HOME pointing to a 32 bit JVM. When the instance wizard runs (under the covers) the JVM is trying to load a 64 bit JNI library that the CP installed.
The fix?
Edit instancewizard.sh and change JAVA_HOME to point to the right JVM. Like so:
JAVA_HOME="/usr/java/latest"
Incidentally I found the root cause by running instancewizard.sh with the -log= and -log_priority= flags. You can run ./instancewazard.sh -h to get the command line help.
Thursday, December 16, 2010
A Quick Note about Oracle Access Manager 11g and WebLogic
A lot of people have been asking me lately about how Oracle Access Manager (OAM) 11g integrates with WebLogic. The answer is very straight forward. OAM 11g integrates with WebLogic using the very same components used to integrate OAM 10.1.4.3. Under most circumstances, that means using the OAM Identity Asserter (the same one used with OAM 10.1.4.3) which asserts the OAM_REMOTE_USER header as the user principal in the JAAS subject. This is used in conjunction with an authentication provider (usually an LDAP provider) which looks up the user in the identity store and builds the rest of the subject based on the group memberships of the user.
You can read more details about integrating OAM and WLS here: http://fusionsecurity.blogspot.com/2010/01/integrating-oracle-access-manager-oam.html
Again, it is important to fully understand how to use the OAM Identity Asserter in a secure solution. I talked about the security of the Identity Asserter a while ago in this post: http://fusionsecurity.blogspot.com/2010/04/security-clarification-oam-identity.html
Thursday, December 9, 2010
Fusion Middleware and Certificate Expirations
I wanted to take a moment to blog about one of the most common, yet most easily preventable causes of middleware system outages. The cause is the expiration of digital certificates used in middleware infrastructure.
Certificates are used throughout many Oracle Fusion Middleware products for purposes of authentication and encryption. This includes:
- Server certificates for SSL in OHS and WLS
- Certificates used for intra and inter product transport communication in WLS, OAM, OAAM, OID, OVD, OIM, OSB etc…
- Certificates used for signing and authentication in OWSM, WLS, OSB, OIF, and Oracle STS.
Despite the fact that digital certificates are such an integral part of middleware infrastructure, you might be surprised how many customers are not well organized about their PKI and in particular about when the different certificates in their infrastructure expire.
It is such a little, simple thing, but all it takes is one expired certificate in one middleware component to bring an application down.
I encourage you today to “not be that customer”, stay organized and keep track of when your certificates expire so that you can issue updated certificates before that happens.
A Note about OAM and the certificates used in Simple Mode
OAM has three different security “modes” for the communication done between the webgate (web server plug-in) and the OAM server component which processes authentication and authorization. These 3 modes are:
- Open: Unencrypted communication
- Simple: Communication over SSL using certificates generated by OAM using an Oracle CA certificate that comes with OAM. Simple mode is popular with customers who want to secure webgate to OAM server communication but don’t feel the need to use their own PKI infrastructure.
- Cert: Communication over SSL using certificates issued by a third party CA.
The mode most relevant to this discussion on expiring certificates is simple mode where the certificates are generated automatically and may be out of sight and mind.
In OAM 10g the certificates are only issued with a validity period of one year by default. If you want to extend the validity period for the certificates generated in simple mode (and I recommend that you do), then follow the instructions in appendix F, section 2.9 of the OAM Identity Admin Guide: http://download.oracle.com/docs/cd/E12530_01/oam.1014/b32419/trblsht.htm#BABDDBJF
In OAM 11g, the validity period of the certificates used in simple mode is 10 years, making early expiration of the certificates less of a problem.
Tuesday, November 30, 2010
Security in Service-Enabled ADF Business Components
This article is a developer-focused tutorial where operations carried by ADF BC (Application Development Framework Business Components) are exposed as web services, so they can be easily integrated into SOA applications. I will describe the end to end development process, starting with service-enabling ADF BC Application Modules, showing how to secure them and how to package the application using JDeveloper.
Service-Enabling ADF Business Components
So let’s take a look at how service-enabling business logic encapsulated in ADF BC looks like. Roughly put, ADF BC comprise 3 main components: Entity Objects (EOs), View Objects (VOs) and Application Modules (AMs). EOs are the object representations of a business domain, VOs are the queries built on top of those objects, giving shape to data, and AMs are the way in which data and business logic is exposed to the outside world. I strongly recommend reading JDeveloper’s embedded documentation on ADF for the full picture. ADF BC is a very powerful framework and aims for quick and consistent development of java-based enterprise-wide applications. It is worth mentioning that is the natural path for the thousands of Oracle Forms customers to enter an SOA world.
AMs are the entry point for encapsulated business logic. They are the components for which web services interfaces are created. Service-enabled AMs are stateless enterprise session beans that are added a SOAP binding. One can expose any AM public custom method or any VO method as a service operation. And each of these operations can be added distinct security policies.
As an example, I am considering an SOA Loan Application. In order to make a decision whether or not the Loan should be granted to the requester, the application needs to query an AM for the requester payment history. This is precisely the AM that I will make available as a SOAP web service.
Here is the sequence:
Couple of things to notice:
a) customerName bind variable, used in the specified view criteria.
b) CustomerPaymentHistoryVCByName view criteria, allowing any name to be added to the query at runtime.
Attention to the Target Namespace field value. That’s vital information when it comes to securing the web service. More on this later.
Also see that there’s an option of generating asynchronous web services methods. I will cover it in a future article.
Click Next button.
b) On the left side, click Service View Instances, pick the VO instance, select it and send it to right side using the blue arrow.
c) Select View Criteria Find Operations tab and click on the green plus sign.
d) Pick the View Criteria that was previously created in step 1 and give the operation a more meaningful name. The binding variable defined for the view criteria is automatically exposed as an input parameter.
Click Ok.
e) The View Criteria gets exposed as a method that takes the binding variable as an input parameter. Click Next.
f) In the summary screen, do notice the Service Interface name (highlighted). It will be used when securing the service.
g) Upon clicking the Finish button, here’s what we get:
Four classes are defined for the Application Module. For the purposes of security we’re interested in the Remote Server Class, which is the web service implementation.
a) To attach the policies, place the cursor over the web service implementation class name (CustomerHistoryAMServiceImpl.java). In the property inspector, under Web Services Extension, under OWSM Policies, click the … button next to Security
b) Pick the following policies from the list:
oracle/wss_username_token_service_policy and oracle/binding_permission_authorization_policy.
Notice they are added as a SecurityPolicy class annotation.
These policies can also be added/removed/changed in Enterprise Manager.
At this point, all operations of our web service will require a valid user, but there’s still no authorization rule governing which users can access the findCustomerPaymentHistoryByName method. Let’s take care of it now.
Here’s the jazn-data.xml snippet.
Attention to lines 15-31. They define the authorization rule for our method.
Line 19 contains the role name granted the permission to invoke the method.
Line 26 defines the permission class that understands the name and actions specified in lines 27 and 28. oracle.wsm.security.WSFunctionPermission is mandatory for authorization rules based on OWSM authorization policies.
Line 27 defines the web service and the operation name being protected. Here is where we need the web service namespace and name, as said in subsection 2f above. You can also find this information in the service wsdl.
The format is <webservice-target-namespace>/<webservice-name>#<method-name>
And yes, you can use * in place of <method-name> and protect all methods in one shot.
Line 28 defines the action. The only available and allowed for webservices at the time of this writing is invoke.
Deploying the Application
To deploy an application like this, it is necessary to create a Business Components Service Interface Deployment Profile and then deploy it to an EAR file.
a) In JDev’s Application Navigator, right-click your project and select New…
Under General Categories, choose Deployment Profile and pick Business Components Service Interface in the right side.
Upon clicking OK button, give it a meaningful name and click OK
The deployment profile gets created.
b) Now, to actually package the application into an EAR file, click the little screen sign next to the application name in JDev’s application navigator, as shown below.
Then pick the deployment profile you have just created and deploy it to an EAR file.
That’s it. Your secured service-enabled ADF BC is ready to de deployed.
Hope this is useful for you. Good luck!
Service-Enabling ADF Business Components
So let’s take a look at how service-enabling business logic encapsulated in ADF BC looks like. Roughly put, ADF BC comprise 3 main components: Entity Objects (EOs), View Objects (VOs) and Application Modules (AMs). EOs are the object representations of a business domain, VOs are the queries built on top of those objects, giving shape to data, and AMs are the way in which data and business logic is exposed to the outside world. I strongly recommend reading JDeveloper’s embedded documentation on ADF for the full picture. ADF BC is a very powerful framework and aims for quick and consistent development of java-based enterprise-wide applications. It is worth mentioning that is the natural path for the thousands of Oracle Forms customers to enter an SOA world.
AMs are the entry point for encapsulated business logic. They are the components for which web services interfaces are created. Service-enabled AMs are stateless enterprise session beans that are added a SOAP binding. One can expose any AM public custom method or any VO method as a service operation. And each of these operations can be added distinct security policies.
As an example, I am considering an SOA Loan Application. In order to make a decision whether or not the Loan should be granted to the requester, the application needs to query an AM for the requester payment history. This is precisely the AM that I will make available as a SOAP web service.
Here is the sequence:
1 – VO definition
This is a read-only VO, meaning it is not based on an EO, so you cannot update data through it. It queries a database for the customer payment history.
Couple of things to notice:
a) customerName bind variable, used in the specified view criteria.
b) CustomerPaymentHistoryVCByName view criteria, allowing any name to be added to the query at runtime.
2 – Service Enabling the AM and exposing View Criteria as a web service method
a) Double-click the AM (CustomerHistoryAM) in the Application Navigator on the left side, click Service Interface (on the right side) and then click the green plus sign on the top right.Attention to the Target Namespace field value. That’s vital information when it comes to securing the web service. More on this later.
Also see that there’s an option of generating asynchronous web services methods. I will cover it in a future article.
Click Next button.
b) On the left side, click Service View Instances, pick the VO instance, select it and send it to right side using the blue arrow.
c) Select View Criteria Find Operations tab and click on the green plus sign.
d) Pick the View Criteria that was previously created in step 1 and give the operation a more meaningful name. The binding variable defined for the view criteria is automatically exposed as an input parameter.
Click Ok.
e) The View Criteria gets exposed as a method that takes the binding variable as an input parameter. Click Next.
f) In the summary screen, do notice the Service Interface name (highlighted). It will be used when securing the service.
g) Upon clicking the Finish button, here’s what we get:
Four classes are defined for the Application Module. For the purposes of security we’re interested in the Remote Server Class, which is the web service implementation.
Securing the web service
Securing the web service here means attaching an OWSM authentication and an authorization policy to it. Both are attached at the service level, meaning all operations are now protected. However, different operations can be granted to different subjects.1 - Adding OWSM Policies to the Web Service
In this example, the authentication policy is a username-based one, which means this web service expects a username token in the incoming SOAP message header. The authorization policy delegates the authorization decision to the OPSS layer, which expects an authorization policy defined in the OPSS policy store.a) To attach the policies, place the cursor over the web service implementation class name (CustomerHistoryAMServiceImpl.java). In the property inspector, under Web Services Extension, under OWSM Policies, click the … button next to Security
b) Pick the following policies from the list:
oracle/wss_username_token_service_policy and oracle/binding_permission_authorization_policy.
Notice they are added as a SecurityPolicy class annotation.
These policies can also be added/removed/changed in Enterprise Manager.
At this point, all operations of our web service will require a valid user, but there’s still no authorization rule governing which users can access the findCustomerPaymentHistoryByName method. Let’s take care of it now.
2 - Adding the OPSS Authorization Rule to the Web Service Operation
As you might think, these authorization rules are expressed in the OPSS policy store. At design time, this translates to creating the rule in jazn-data.xml. Let’s assume that we only want to allow members of the manager role to invoke the findCustomerPaymentHistoryByName method.Here’s the jazn-data.xml snippet.
Attention to lines 15-31. They define the authorization rule for our method.
1: <?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
2: <jazn-data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3: xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/jazn-data-11_0.xsd">
4: <policy-store>
5: <applications>
6: <application>
7: <name>CustomerHistory</name>
8: <app-roles>
9: <app-role>
10: <name>managers</name>
11: <class>oracle.security.jps.service.policystore.ApplicationRole</class>
12: </app-role>
13: </app-roles>
14: <jazn-policy>
15: <grant>
16: <grantee>
17: <principals>
18: <principal>
19: <name>managers</name>
20: <class>oracle.security.jps.service.policystore.ApplicationRole</class>
21: </principal>
22: </principals>
23: </grantee>
24: <permissions>
25: <permission>
26: <class>oracle.wsm.security.WSFunctionPermission</class>
27: <name>/customerhistory/common/CustomerHistoryAMService#findCustomerPaymentHistoryByName</name>
28: <actions>invoke</actions>
29: </permission>
30: </permissions>
31: </grant>
32: </jazn-policy>
33: </application>
34: </applications>
35: </policy-store>
36: </jazn-data>
Line 26 defines the permission class that understands the name and actions specified in lines 27 and 28. oracle.wsm.security.WSFunctionPermission is mandatory for authorization rules based on OWSM authorization policies.
Line 27 defines the web service and the operation name being protected. Here is where we need the web service namespace and name, as said in subsection 2f above. You can also find this information in the service wsdl.
The format is <webservice-target-namespace>/<webservice-name>#<method-name>
And yes, you can use * in place of <method-name> and protect all methods in one shot.
Line 28 defines the action. The only available and allowed for webservices at the time of this writing is invoke.
Deploying the Application
To deploy an application like this, it is necessary to create a Business Components Service Interface Deployment Profile and then deploy it to an EAR file.
a) In JDev’s Application Navigator, right-click your project and select New…
Under General Categories, choose Deployment Profile and pick Business Components Service Interface in the right side.
Upon clicking OK button, give it a meaningful name and click OK
The deployment profile gets created.
b) Now, to actually package the application into an EAR file, click the little screen sign next to the application name in JDev’s application navigator, as shown below.
Then pick the deployment profile you have just created and deploy it to an EAR file.
That’s it. Your secured service-enabled ADF BC is ready to de deployed.
Hope this is useful for you. Good luck!
Tuesday, November 2, 2010
OES Security Module Logging in WebLogic domains with Enterprise Manager
This isn't the "official" solution, but a quick note on how I jury rigged my logging to get it working.
Both the OES WebLogic SM and the Enterprise Manager seem to use log4j to do their logging. Since the SM spins up first you will see the normal sorts of things you'd expect in the OES SM's log file as the SM WebLogic server boots. Then suddenly the log juts stops.
This is because the Enterprise Manager app (EM) re-initializes the log4j system with its own config file. To solve it just add the lines you want from OES' log4j.properties to the config file ./config/fmwconfig/servers/AdminServer/applications/em/META-INF/emomslogging.properties
Hope this helps someone else!
Both the OES WebLogic SM and the Enterprise Manager seem to use log4j to do their logging. Since the SM spins up first you will see the normal sorts of things you'd expect in the OES SM's log file as the SM WebLogic server boots. Then suddenly the log juts stops.
This is because the Enterprise Manager app (EM) re-initializes the log4j system with its own config file. To solve it just add the lines you want from OES' log4j.properties to the config file ./config/fmwconfig/servers/AdminServer/applications/em/META-INF/emomslogging.properties
Hope this helps someone else!
Wednesday, October 27, 2010
Keystores and signing your SAML assertions
I've been working on a project recently that includes SOAP clients submitting messages via JMS and HTTP to Oracle Service Bus (OSB). OSB is supposed to validate the assertion, perhaps do some transformations on the SOAP, and then send the message off to some backend service. I'll probably talk about the last two thirds of the solution at some point in the future, but it's the first third that has raised a bunch of questions that other people probably have too.
Before I go into the details let me just remind you that the details here are specific to this customer's situation. I'm not advocating for, endorsing or otherwise suggesting that the info here is useful to YOUR situation. With that said...
The customer's architecture includes submitting the messages over a 2-way SSL channel and they want to use SAML 1.1 assertions with the Bearer confirmation method. Most people are probably more familiar with the Sender Vouches method in which the entity sending the SAML assertion (i.e. the SOAP client) is trusted by the receiving party - which means that every client needs a private key and the receiver needs to have the associated Certificate (or the issuer's Certificate).
In Bearer the sender of the message isn't necessarily the party that actually created the SAML Assertion; if they were then you could just use Sender Vouches and be done. In Bearer you're saying that the communication channel authenticates the caller; this also means that the party sending the message could get a SAML assertion from somewhere else and then just includes it in the SOAP message. There are a bunch of dangers in this sort of architecture, but you can mitigate most of them through appropriate architectural choices. What those dangers are and how you mitigate them is a subject for a separate post. There's a third confirmation method called Holder of Key which is, again, a great subject for another post.
In Bearer the sender of the message isn't necessarily the party that actually created the SAML Assertion; if they were then you could just use Sender Vouches and be done. In Bearer you're saying that the communication channel authenticates the caller; this also means that the party sending the message could get a SAML assertion from somewhere else and then just includes it in the SOAP message. There are a bunch of dangers in this sort of architecture, but you can mitigate most of them through appropriate architectural choices. What those dangers are and how you mitigate them is a subject for a separate post. There's a third confirmation method called Holder of Key which is, again, a great subject for another post.
In any case when you use the Bearer Confirmation Method you might want the assertion to be signed, especially if it comes from somewhere other than the client. So who has the private key? And what certificates do you need to put in the keystore?
When you install WebLogic the installer automatically creates a couple of keystores for you. Gerard Davison discusses this a bit in a blog post in the context of setting up SSL. We can use the same keystores for testing SOAP.
First here's the table (shamelessly copied) from Gerard's post:
As you can see there are two JKS files - DemoTrust.jks and DemoIdentity.jks. Take a look at the contents of them by using keytool:
You'll find that DemoIdentity.jks contains a Private Key and DemoTrust.jks contains the associated Certificate (and a few others).
So for my little SOAP tester in my test environment I can use the DemoIdentity.jks file to sign the SAML Assertion and as long as OSB is configured to use DemoTrust.jks it should accept my SAML Assertion.
In the real world you definitely won't be using the DemoTrust keystore. Instead you'll create another Key Store to be used on the OSB server and you'll probably put the Certificate of the SAML assertion generator in there (if it's a self-signed cert) or the Cert chain needed to verify the signature.
Hope this helps!
First here's the table (shamelessly copied) from Gerard's post:
| Property | Value |
| Trust store location | wlserver_10.3/ server/lib/DemoTrust.jks |
| Trust store password | DemoTrustKeyStorePassPhrase |
| Key store location | wlserver_10.3/ server/lib/DemoIdentity.jks |
| Key store password | DemoIdentityKeyStorePassPhrase |
| Private key password | DemoIdentityPassPhrase |
As you can see there are two JKS files - DemoTrust.jks and DemoIdentity.jks. Take a look at the contents of them by using keytool:
keytool -list -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase keytool -list -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase
You'll find that DemoIdentity.jks contains a Private Key and DemoTrust.jks contains the associated Certificate (and a few others).
I'm a huge fan of automated unit test tools. I'll often invest literally tens of hours writing test drivers that will be thrown away when the project is done just so I can be sure that I haven't missed anything. More importantly I want to be 100% sure that we've got test coverage for all of the positive and negative cases we've thought of in the design phase.
So for my little SOAP tester in my test environment I can use the DemoIdentity.jks file to sign the SAML Assertion and as long as OSB is configured to use DemoTrust.jks it should accept my SAML Assertion.
In the real world you definitely won't be using the DemoTrust keystore. Instead you'll create another Key Store to be used on the OSB server and you'll probably put the Certificate of the SAML assertion generator in there (if it's a self-signed cert) or the Cert chain needed to verify the signature.
Hope this helps!
Monday, October 25, 2010
Quick tip: OVD – Providing namespace translation for DN attributes
Breaking off the ADF/OPSS series…
OVD (Oracle Virtual Directory) guru Mark Wilcox gave me this really helpful tip that it’s worth sharing. It can save you folks quite a bit of headache.
Scenario: you have configured an OVD authentication provider in WLS, but you cannot login with any user from OVD in WLS Console, even the user being a member of an Administrators group in the backend LDAP directory. When you try it, you end up with an “Authentication Denied” error. And if you login into WLS Console in the “normal” way (i.e., using weblogic user from Default Authenticator provider) you don’t see the OVD users memberships. These two problems are definitely related.
Solution: you need to change the LDAP adapter definition in OVD a bit. Connect to ODSM (Oracle Directory Services Manager), retrieve your adapter, click on the General tab and add uniquemeber as one of DN Attributes, as shown:
OVD translates all attributes listed as DN Attributes. Translation here means converting the backend repository (in this case OID) namespace into the adapter’s namespace. In this example, OID namespace is dc=us,dc=oracle,dc=com, while adapter’s is ou=oid,dc=us,dc=oracle,dc=com. Without the translation, uniquemembers of a group would end up being cn=<user>,dc=us,dc=oracle,dc=com. With the translation, they align nicely with the adapter’s namespace: cn=<user>,ou=oid,dc=us,dc=oracle,dc=com.
No need to restart anything. You should now be able to see users memberships as well as login in WLS Console with administrators users defined in the OVD authentication provider.
Note: this has been done in Oracle Identity Management 11g PS2.
Wednesday, October 20, 2010
Several ADF apps to one single OPSS policy stripe
In OPSS Artifacts Life Cycle in ADF Applications, I’ve explained how to change the default behavior for migration of authorization policies when deploying applications. Revisiting it, I’ve said that one can specify the MERGE value for jps.policystore.migration param-name in weblogic-application.xml and that is particularly useful in some deployments where more than one application have to share the same policy context (or policy stripe).
A real use case is when a customer wants to hide the concept of how a system is partitioned across ADF applications for security administrators. Most of the times, a security administrator is interested in the policies of the system as whole. This article explains how it can be done.
Before going further, some definitions:
When we develop an ADF application in JDeveloper and enables ADF security, the authorization policies you create go into a workspace-level jazn-data.xml under a stripe name that has the same name as the application itself, as show below. Let’s say our application is called OrderEntry. In jazn-data, we would have:
Then if you do nothing and just deploy the application, the policies get migrated to the runtime policy store under an application policy stripe named OrderEntry#V2.0. For our mental sanity, the V2.0 comes from the Weblogic-Application-Version property in the MANIFEST.MF, but this is not the topic of this article.
Now what happens if we want to have OrderEntry and OrderCapture binding to the same policy stripe, say OrderMgmt? We need to add some properties to some deployment descriptors:
1) in weblogic-application.xml:
<application-param>
Such information is used only at deployment time. It basically tell the OPSS listeners to migrate application policies in jazn-data.xml to OrderMgmt policy stripe in the runtime policy store. In this scenario, the version number is not appended to the stripe name.
2) in web application’s web.xml:
Here I have added the init-param application.name to the JpsFilter definition. The param-value must match the value defined in weblogic-application.xml. This information is used only at runtime. It tells the JpsFilter where to bind to when looking for authorization policies. As the JpsFilter intercepts all requests for the Faces Servlet (javax.faces.webapp.FacesServlet), it establishes the policy store context for every request to an ADF artifact.
By repeating this very same configuration across your applications, you can bind any number of applications to the same policy stripe, i.e., the same authorization context and expose a single and consolidated view of your authorization policies to security administrators.
A real use case is when a customer wants to hide the concept of how a system is partitioned across ADF applications for security administrators. Most of the times, a security administrator is interested in the policies of the system as whole. This article explains how it can be done.
Before going further, some definitions:
- Policy Store: repository of policies comprising one or more application policy stripes and code-based grants. There’s only one policy store per WLS domain.
- Policy Stripe: set of application policies to which one or more applications bind to. One application binds to only one policy stripe.
<?xml version='1.0' encoding='utf-8'?>
<jazn-data>
<policy-store>
<applications>
<application>
<name>OrderEntry#V2.0</name>
<app-roles>
...
</app-roles>
<jazn-policy>
...
</jazn-policy>
</application>
<application>
<name>OrderCapture#V2.0</name>
<app-roles>
...
</app-roles>
<jazn-policy>
...
</jazn-policy>
</application>
</applications>
</policy-store>
</jazn-data>
When we develop an ADF application in JDeveloper and enables ADF security, the authorization policies you create go into a workspace-level jazn-data.xml under a stripe name that has the same name as the application itself, as show below. Let’s say our application is called OrderEntry. In jazn-data, we would have:
<?xml version='1.0' encoding='utf-8'?>
<jazn-data>
<policy-store>
<applications>
<application>
<name>OrderEntry</name>
<app-roles>
...
</app-roles>
<jazn-policy>
...
</jazn-policy>
</application>
</applications>
</policy-store>
</jazn-data>
Now what happens if we want to have OrderEntry and OrderCapture binding to the same policy stripe, say OrderMgmt? We need to add some properties to some deployment descriptors:
1) in weblogic-application.xml:
<application-param>
<param-name>jps.policystore.applicationid</param-name>
<param-value>OrderMgmt</param-value>
</application-param>
Such information is used only at deployment time. It basically tell the OPSS listeners to migrate application policies in jazn-data.xml to OrderMgmt policy stripe in the runtime policy store. In this scenario, the version number is not appended to the stripe name.
2) in web application’s web.xml:
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>enable.anonymous</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>remove.anonymous.role</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>application.name</param-name>
<param-value>OrderMgmt</param-value>
</init-param>
</filter>
Here I have added the init-param application.name to the JpsFilter definition. The param-value must match the value defined in weblogic-application.xml. This information is used only at runtime. It tells the JpsFilter where to bind to when looking for authorization policies. As the JpsFilter intercepts all requests for the Faces Servlet (javax.faces.webapp.FacesServlet), it establishes the policy store context for every request to an ADF artifact.
By repeating this very same configuration across your applications, you can bind any number of applications to the same policy stripe, i.e., the same authorization context and expose a single and consolidated view of your authorization policies to security administrators.
Subscribe to:
Posts (Atom)
Posts
