To validate
the integration with OES we need a sample ADF Application that is rich enough to allow us to test securing
the various ADF elements. To achieve this we can add some items including bounded task flows to
the application developed in this tutorial. A sample JDeveloper 11.1.1.6 project is available here. It depends on
the Fusion Order Demo (FOD) database schema which is easily created using
the FOD build scripts.In
the deployment we have chosen to enable only ADF Authentication as we will delegate Authorization, mostly, to OES.
The welcome page of
the application with all
the links exposed looks as follows:
The Welcome, Browse Products, Browse Stock and System Administration links go to pages while
the Supplier Registration and Update Stock are bounded task flows.
The Login link goes to a basic login page and once logged in a link is presented that goes to a logout page. Only
the Browse Products and Browse Stock pages are really connected to
the database--the other pages and task flows do not really perform any operations on
the database.
Required Security Policies
We make use of a set of test users and roles as decscribed on
the welcome page of
the application. In order to exercise
the different authorization possibilities we would like to enforce
the following sample policies:
Anonymous users can see
the Login, Welcome and Supplier Registration links. They can also see
the Welcome page,
the Login page and follow
the Supplier Registration task flow. They can see
the icon adjacent to
the Login link indicating whether they have logged in or not.
Authenticated users can see
the Browse Product page.
Only staff granted
the right can see
the Browse Product page cost price value returned from
the database and then only if
the value is below a configurable limit.
Suppliers and staff can see
the Browse Stock links and pages. Customers cannot.
Suppliers can see
the Update Stock link but only those with
the update permission are allowed to follow
the task flow that it launches. We could hide
the link but leave it exposed here so we can easily demonstrate
the method call activity protecting
the task flow.
Only staff granted
the right can see
the System Administration link and
the System Administration page it accesses.
Implementing
the required policies
In order to secure
the application we will make use of
the following techniques:
EL Expressions and Java backing beans: JSF has
the notion of EL expressions to reference data from backing Java classes. We use these to control
the presentation of links on
the navigation page which respect
the security contraints. So a user will not see links that he is not allowed to click on into. These Java backing beans can call on to OES for an authorization decision. Important Note: naturally we would configure
the WLS domain where our ADF application is running as an OES WLS SM, which would allow us to efficiently query OES over
the PEP API. However versioning conflicts between OES 11.1.1.5 and ADF 11.1.1.6 mean that this is not possible. Nevertheless, we can make use of
the OES RESTful gateway technique from this posting in order to call into OES.
You can easily create and manage backing beans in Jdeveloper as follows:
Custom ADF Phase Listener: ADF extends
the JSF page lifecycle flow and allows one to hook into
the flow to intercept page rendering. We use this to put a check prior to rendering any protected pages, again calling on to OES via
the backing bean. Phase listeners are configured in
the adf-settings.xml file. See
the MyPageListener.java class in
the project. Here, for example, is
the code we use in
the listener to check for allowed access to
the sysadmin page, navigating back to
the welcome page if authorization is not granted:
if (page != null && (page.equals("/system.jspx") || page.equals("/system"))){ System.out.println("MyPageListener: Checking Authorization for /system"); if (getValue("#{oesBackingBean.UIAccessSysAdmin}").toString().equals("false") ){ System.out.println("MyPageListener: Forcing navigation away from system" + "to welcome"); NavigationHandler nh = fc.getApplication().getNavigationHandler(); nh.handleNavigation(fc, null, "welcome"); } else { System.out.println("MyPageListener: access allowed"); } }
Method call activity: our app makes use of bounded task flows to implement
the sequence of pages that update
the stock or allow suppliers to self register. ADF takes care of ensuring that a bounded task flow can be entered by only one page. So a way to protect all those pages is to make a call to OES in
the first activity and then either exit
the task flow or continue depending on
the authorization decision.
The method call returns a String which contains
the name of
the transition to effect. This is where we configure
the method call activity in JDeveloper:
We implement each of
the policies using
the above techniques as follows:
Policies 1 and 2: as these policies concern
the coarse grained notions of controlling access to anonymous and authenticated users we can make use of
the container’s security constraints which can be defined in
the web.xml file.
The allPages constraint is added automatically when we configure Authentication for
the ADF application. We have added
the “anonymousss” constraint to allow access to
the the required pages, task flows and icons:
<security-constraint> <web-resource-collection> <web-resource-name>anonymousss</web-resource-name> <url-pattern>/faces/welcome</url-pattern> <url-pattern>/afr/*</url-pattern> <url-pattern>/adf/*</url-pattern> <url-pattern>/key.png</url-pattern> <url-pattern>/faces/supplier-reg-btf/*</url-pattern> <url-pattern>/faces/supplier_register_complete</url-pattern> </web-resource-collection> </security-constraint>
Policy 3: we can place an EL expression on
the element representing
the cost price on
the products.jspx page: #{oesBackingBean.dataAccessCostPrice}. This EL Expression references a method in a Java backing bean that will call on to OES for an authorization decision. In OES we model
the authorization requirement by requiring
the view permission on
the resource /MyADFApp/data/costprice and granting it only to
the staff application role. We recover any obligations to determine
the limit.
Policy 4: is implemented by putting an EL expression on
the Browse Stock link #{oesBackingBean.UIAccessBrowseStock} which checks for
the view permission on
the /MyADFApp/ui/stock resource.
The stock.jspx page is protected by checking for
the same permission in a custom phase listener—if
the required permission is not satisfied then we force navigation back to
the welcome page.
Policy 5:
the Update Stock link is protected with
the same EL expression as
the Browse Link: #{oesBackingBean.UIAccessBrowseStock}. However
the Update Stock link launches a bounded task flow and to protect it
the first activity in
the flow is a method call activity which will execute an EL expression #{oesBackingBean.isUIAccessSupplierUpdateTransition} to check for
the update permission on
the /MyADFApp/ui/stock resource and either transition to
the next step in
the flow or terminate
the flow with an authorization error.
Policy 6:
the System Administration link is protected with an EL Expression #{oesBackingBean.UIAccessSysAdmin} that checks for view access on
the /MyADF/ui/sysadmin resource.
The system page is protected in
the same way at
the stock page—the custom phase listener checks for
the same permission that protects
the link and if not satisfied we navigate back to
the welcome page.
Testing
the Application
To test
the application:
deploy
the OES11g Admin to a WLS domain
deploy
the OES gateway in a another domain configured to be a WLS SM. You must ensure that
the jps-config.xml file therein is configured to allow access to
the identity store, otherwise
the gateway will not b eable to resolve
the principals for
the requested users. To do this ensure that
the following elements appear in
the jps-config.xml file:
<serviceProvider type="IDENTITY_STORE" name="idstore.ldap.provider" class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider"> <description>LDAP-based IdentityStore Provider</description> </serviceProvider>
<serviceInstance name="idstore.ldap" provider="idstore.ldap.provider"> <property name="idstore.config.provider" value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"/> <property name="CONNECTION_POOL_CLASS" value="oracle.security.idm.providers.stdldap.JNDIPool"/></serviceInstance>
<serviceInstanceRef ref="idstore.ldap"/>
download
the sample application and change
the URL to
the gateway in
the MyADFApp OESBackingBean code to point to
the OES
Gateway and deploy
the application to an 11.1.1.6 WLS domain that has been extended with
the ADF JRF files. You will need to configure
the FOD database connection to point your database which contains
the FOD schema.
populate
the OES Admin and OES Gateway WLS LDAP stores with
the sample set of users and groups. If you have configured
the WLS domains to point to
the same LDAP then it would only have to be done once. To help with this there is a directory called ldap_scripts in
the sample project with ldif files for
the test users and groups.
start
the OES Admin console and configure
the required OES authorization policies for
the MyADFApp application and push them to
the WLS SM containing
the OES Gateway.
Login to
the MyADFApp as each of
the users described on
the login page to test that
the security policy is correct.
You will see informative logging from
the OES Gateway and
the ADF application to their respective WLS consoles.
Congratulations, you may now login to
the OES Admin console and change policies that will control
the behaviour of your ADF application--change
the limit value in
the obligation for
the cost price for example, or define Role Mapping policies to determine staff access to
the system administration page based on user profile attributes.
ADF Development Notes
Some notes on ADF development which are probably typical gotchas:
May need this on WLS startup in order to allow us to overwrite credentials for
the database,
the signal here is that there is an error trying to access
the data base: -Djps.app.credential.overwrite.allowed=true
Best to call Bounded Task flows via a CommandLink (as opposed to a go link) as you cannot seem to start them again from a go link, even having completed
the task flow correctly with a return activity.
Once a bounded task flow (BTF) is initated it must complete correctly via a return activity—attempting to click on any other link whilst in
the context of a BTF has no effect. See here for example:
When using
the ADF Authentication only security approach it seems to be awkward to allow anonymous access to
the welcome and registration pages. We can achieve anonymous access using
the web.xml security constraint shown above (where no auth-constraint is specified) however it is not clear what needs to be listed in there….for example
the /afr/* and /adf/* are in there by trial and error as sometimes
the welcome page will not render if we omit those items. I was not able to use
the default allPages constraint with for example
the anonymous-role or
the everyone WLS group in order to be able to allow anonymous access to pages.
The ADF security best practice advises placing all pages under
the public_html/WEB-INF folder as then ADF will not allow any direct access to
the .jspx pages but will only allow acces via a link of
the form /faces/welcome rather than /faces/welcome.jspx. This seems like a very good practice to follow as having multiple entry points to data is a source of confusion in a web application (particulary from a security point of view).
In Authentication+Authorization mode only pages with a Page definition file are protected. In order to add an emty one right click on
the page and choose Go to Page Definition. This will create an empty page definition and now
the page will require explicit permission to be seen.
It is advisable to give a unique context root via
the weblogic.xml for
the application, as otherwise
the application will clash with any other application with
the same context root and it will not deploy
