Chris Muir
ADF 11gR1 – UI Shell – Oracle Dynamic Tabs Shell
In the latest release of JDeveloper, specifically 11.1.1.2.0 also known as 11g Release 1 also known as Patch Set 1 also known as 11g build 5536 also known as the Shepherd build (cough cough Oracle), Oracle has included a new built in page template known as the "Oracle Dynamic Tabs Shell". This template is part of Oracle's ADF Functional Patterns and Best Practices efforts, also referred to as the "UI Shell". Complete documentation is available here. I'll leave readers unfamiliar with the UI Shell to read Oracle's documentation to understand the basics.
With my current client we're happy with the inclusion of this new UI Shell and we can actively see ourselves using it in the near future. What I wanted to document is my own thoughts and research which may be of use to others, and I hope to further the discussion on the ADF EMG. Note as usual your mileage may vary so take time out to check the facts listed here:
1) The Create JSF Page dialog presents the "Oracle Dynamic Tabs Shell" page template option:
2) The template and its supporting classes are installed in <jdev_home>/jdeveloper/adfv/jlib/oracle-page-templates-ext.jar, though the JDev IDE takes care of importing the template and classes/libraries into your project for you once selected in the Create JSF Page dialog. As the following picture shows an additional library Oracle Extended Page Templates is added to your project:
Side note: Steve Muench has blogged the location of the UI Shell template and supporting classes as a separate download here. This will allow you to take the default UI Shell template and customise to your needs if required. See further points below for why this may be necessary.
2) Our technical team was already getting bogged down in "discussions" of "standard" web page layouts versus RIA layouts. The technical team knows the standard web page layouts weren't suited to RIA applications, but it was hard to argue our case without actually creating a RIA layout. In turn creating a RIA layout that we were happy with was going to take some time, and we're building applications now. With the UI Shell we can short cut the layout "discussions", say this is what Oracle's provided us, it works well and this is what we'll use, allowing us to focus on the more important matter of hand and that's writing the ADF solution for the business.
3) Our overall application is made up of several subsystems (think Oracle Apps with HR, Procurement, Payroll etc). Within the UI Shell the globalTabs facet provides an ideal location to list the subsystems allowing the user to switch between each module:
4) Each subsystem gets its own page based on the template, as in hr.jspx, procurement.jspx and payroll.jspx based on our example.
5) The rest of the application is made up of a number "Activities" that in essence are bounded task flows using page fragments, or in other words the business processes of your application. Each subsystem is free to make use of as many bounded task flows as it sees fit, and in addition a bounded task flow can be used (shared) by many of the subsystem pages.
6) As per the previous point, if you're using the default UI Shell provided through JDeveloper rather than downloading the UI Shell as per Steve Muench's blog above, and you wish to have a common element in every page using the template, you'll need to code them in every page which isn't ideal. The solution is to download Oracle's template and customise it within your own application (or possibly create a number of declarative page components for repetitive content, though this will still require you to load each page component in each page based on the UI Shell template).
7) A key feature of the UI Shell as described in its other name "Oracle Dynamic Tabs Shell" is it shows under each subsystem how to launch a bounded task flow (aka Activity) one or many times:
This may not be ideal for every application, but my current client has a scenario in an existing Oracle Forms application where users open up to 4 sessions. While we're not sure on building an ADF equivalent with a chance to redesign the users' workflow will they still need to do this, if they do we're envisaging that each session can now be as a separate UI Shell Activity under the subsystem page.
8) As discussed in the following ADF EMG thread the UI Shell makes a great addition to the "Master JDev Application Workspace" proposed by Todd Hill bringing a number of composite ADF bounded task flows together.
9) The demonstration UI Shell application shows a basic mechanism of stopping a user leaving an activity once they've made "it dirty". The analogy to this is in the JDev IDE when the user changes the contents of a source file, the tab control title font becomes italic and the user is warned/prompted to save changes if they attempt to close the tab without saving.
Currently this feature should be considered a demonstration feature only as in the downloadable UI Shell demonstration application it has a number of limitations (it is a demo after all). In particular the isDirty() check is only done within a subsystem's activities. Clicking on a different subsystem tab/page doesn't invoke the isDirty() check with the appropriate warning dialog. It would be my assumption that this check would need to be coded in each specific application, reusing the isDirty() facilities provided.
10) For the logoImagePath attribute you can specify the path of the UI Shell log image, but not the size. In the turn the layout tends to assume a horizontal logo. If corporate branding is important to your organisation and they have a long vertical logo, good luck.
11) The default UI Shell has no consideration of security. For instance what subsystems are available under the globalTabs for the current user is your responsibility
12) The overall template does waste some vertical screen real-estate:
See annotations A, B and C.
A can be trimmed by setting the globalSplitterPosition attribute. At this time it doesn't look like B and C can be set in the default UI Shell. Ideally we'd want something like this:
13) The overall template is extremely small – only 74k – wow, Oracle can create something that doesn't take up an entire CD! ;-)
14) I note in the source code downloadable from Steve Muench's blog that there are a few comments that the implementation will change dependent on later updates to the ADF component set presumably available in later JDev releases (ie. see the TabContext.java REMOVE_ME_WHEN_NAVPANE_SUPPORTS_STAMPING comment).
This implies the default functionality of the UI Shell could change in the future which could have issues for your existing applications based on the UI Shell and therefore your regression testing and user experience. It may be necessary to source the UI Shell code and baseline in your code repository rather than being subjected to changes in functionality on upgrading to future JDev releases.
15) As per the UI Shell whitepaper, the 7 zillion steps to reproduce the demonstration UI Shell application do look daunting. However if you're familiar with JDev, page templates and constructing JSF pages it only takes about 20-30 minutes to run through most of the steps. In fact most steps are just setting up dummy task flows and page fragments to show some content within the produced template, nothing really to do with the template itself.
16) You'll need to remind users/analysts/managers etc that what the UI Shell gives in preconfigured layouts, saving developers time and boosting productivity, it takes away in customizable layout of the screen. This is a common point of contention in component based frameworks where a super component gives a large array of features, but the component works as the component works and cannot be easily customised without headache.
With my current client we're happy with the inclusion of this new UI Shell and we can actively see ourselves using it in the near future. What I wanted to document is my own thoughts and research which may be of use to others, and I hope to further the discussion on the ADF EMG. Note as usual your mileage may vary so take time out to check the facts listed here:
1) The Create JSF Page dialog presents the "Oracle Dynamic Tabs Shell" page template option:
2) The template and its supporting classes are installed in <jdev_home>/jdeveloper/adfv/jlib/oracle-page-templates-ext.jar, though the JDev IDE takes care of importing the template and classes/libraries into your project for you once selected in the Create JSF Page dialog. As the following picture shows an additional library Oracle Extended Page Templates is added to your project:
Side note: Steve Muench has blogged the location of the UI Shell template and supporting classes as a separate download here. This will allow you to take the default UI Shell template and customise to your needs if required. See further points below for why this may be necessary.2) Our technical team was already getting bogged down in "discussions" of "standard" web page layouts versus RIA layouts. The technical team knows the standard web page layouts weren't suited to RIA applications, but it was hard to argue our case without actually creating a RIA layout. In turn creating a RIA layout that we were happy with was going to take some time, and we're building applications now. With the UI Shell we can short cut the layout "discussions", say this is what Oracle's provided us, it works well and this is what we'll use, allowing us to focus on the more important matter of hand and that's writing the ADF solution for the business.
3) Our overall application is made up of several subsystems (think Oracle Apps with HR, Procurement, Payroll etc). Within the UI Shell the globalTabs facet provides an ideal location to list the subsystems allowing the user to switch between each module:
4) Each subsystem gets its own page based on the template, as in hr.jspx, procurement.jspx and payroll.jspx based on our example.5) The rest of the application is made up of a number "Activities" that in essence are bounded task flows using page fragments, or in other words the business processes of your application. Each subsystem is free to make use of as many bounded task flows as it sees fit, and in addition a bounded task flow can be used (shared) by many of the subsystem pages.
6) As per the previous point, if you're using the default UI Shell provided through JDeveloper rather than downloading the UI Shell as per Steve Muench's blog above, and you wish to have a common element in every page using the template, you'll need to code them in every page which isn't ideal. The solution is to download Oracle's template and customise it within your own application (or possibly create a number of declarative page components for repetitive content, though this will still require you to load each page component in each page based on the UI Shell template).
7) A key feature of the UI Shell as described in its other name "Oracle Dynamic Tabs Shell" is it shows under each subsystem how to launch a bounded task flow (aka Activity) one or many times:
This may not be ideal for every application, but my current client has a scenario in an existing Oracle Forms application where users open up to 4 sessions. While we're not sure on building an ADF equivalent with a chance to redesign the users' workflow will they still need to do this, if they do we're envisaging that each session can now be as a separate UI Shell Activity under the subsystem page.8) As discussed in the following ADF EMG thread the UI Shell makes a great addition to the "Master JDev Application Workspace" proposed by Todd Hill bringing a number of composite ADF bounded task flows together.
9) The demonstration UI Shell application shows a basic mechanism of stopping a user leaving an activity once they've made "it dirty". The analogy to this is in the JDev IDE when the user changes the contents of a source file, the tab control title font becomes italic and the user is warned/prompted to save changes if they attempt to close the tab without saving.
Currently this feature should be considered a demonstration feature only as in the downloadable UI Shell demonstration application it has a number of limitations (it is a demo after all). In particular the isDirty() check is only done within a subsystem's activities. Clicking on a different subsystem tab/page doesn't invoke the isDirty() check with the appropriate warning dialog. It would be my assumption that this check would need to be coded in each specific application, reusing the isDirty() facilities provided.
10) For the logoImagePath attribute you can specify the path of the UI Shell log image, but not the size. In the turn the layout tends to assume a horizontal logo. If corporate branding is important to your organisation and they have a long vertical logo, good luck.
11) The default UI Shell has no consideration of security. For instance what subsystems are available under the globalTabs for the current user is your responsibility
12) The overall template does waste some vertical screen real-estate:
See annotations A, B and C.A can be trimmed by setting the globalSplitterPosition attribute. At this time it doesn't look like B and C can be set in the default UI Shell. Ideally we'd want something like this:
13) The overall template is extremely small – only 74k – wow, Oracle can create something that doesn't take up an entire CD! ;-)14) I note in the source code downloadable from Steve Muench's blog that there are a few comments that the implementation will change dependent on later updates to the ADF component set presumably available in later JDev releases (ie. see the TabContext.java REMOVE_ME_WHEN_NAVPANE_SUPPORTS_STAMPING comment).
This implies the default functionality of the UI Shell could change in the future which could have issues for your existing applications based on the UI Shell and therefore your regression testing and user experience. It may be necessary to source the UI Shell code and baseline in your code repository rather than being subjected to changes in functionality on upgrading to future JDev releases.
15) As per the UI Shell whitepaper, the 7 zillion steps to reproduce the demonstration UI Shell application do look daunting. However if you're familiar with JDev, page templates and constructing JSF pages it only takes about 20-30 minutes to run through most of the steps. In fact most steps are just setting up dummy task flows and page fragments to show some content within the produced template, nothing really to do with the template itself.
16) You'll need to remind users/analysts/managers etc that what the UI Shell gives in preconfigured layouts, saving developers time and boosting productivity, it takes away in customizable layout of the screen. This is a common point of contention in component based frameworks where a super component gives a large array of features, but the component works as the component works and cannot be easily customised without headache.
ADF EMG goes international - UKOUG style
I'm happy to say that the ADF Enterprise Methodology Group is running its first UKOUG presentation this year at their annual technology conference in Birmingham November 30th-December 2nd. This is a pretty exciting development for us, as this will be the first ADF EMG session run outside of the USA!
My colleague in ADF crime Simon Haslam, who organised and ran our OOW sessions this year, invites anybody who is interested in ADF and wants to talk with other users to attend. At OOW we had the rather pleasing experience of several ADF "production" system demonstrations which was pretty cool, and hopefully at the UKOUG we can get some of you to talk about your ADF experiences too.
Unfortunately I'm just on 14590.82kms away (9066.56 miles for our UK friends) and wont be able to make it. If only it was a couple clicks closer, oh, and not across several oceans & continents, and a tad warmer too.
My colleague in ADF crime Simon Haslam, who organised and ran our OOW sessions this year, invites anybody who is interested in ADF and wants to talk with other users to attend. At OOW we had the rather pleasing experience of several ADF "production" system demonstrations which was pretty cool, and hopefully at the UKOUG we can get some of you to talk about your ADF experiences too.
Unfortunately I'm just on 14590.82kms away (9066.56 miles for our UK friends) and wont be able to make it. If only it was a couple clicks closer, oh, and not across several oceans & continents, and a tad warmer too.
ADF BC Groovy – showing old values along with new.
A common requirement in databound applications is to allow the user to view changes before they commit them to the database, showing the user both the original-old value along with the new. This gives users a chance to review their changes visually by comparing the old and new.
For an updated record that has yet been committed to the database, ADF BC stores both the old and new value. Among other reasons ADF BC does this, is it allows the user to cancel any changes, and rather than having to fetch the original value back from the database, ADF BC just retrieves the old value it has cached without a roundtrip to the database.
This cache gives us the ability to solve our original requirements as the ADF BC framework exposes methods to fetch both new and old non committed values from the Entity Object (EO). To fetch the new current value we call the associated accessor such as getPosition() or getName() that was automatically created by the framework in our EntityImpl. To get the old value we use the getPostedAttribute() method passing in the index of the field we wish to fetch.
In JDeveloper 11g through its introduction of Groovy expressions, it's very simple to expose the old value through the Entity Objects:
1) In your required EO create a transient attribute. For example if we want to show the old values for the Position attribute of our EO, we could create a new transient attribute named OldPosition.
2) Ensure the "Persistent" and "Derived from SQL Expression" properties are turned off for the new transient attribute.
3) Set the "Value Type" to Expression and enter the following Groovy expression into the Value field:
adf.object.getPostedAttribute(adf.object.getAttributeIndexOf(model.EmployeesImpl.POSITION))
Note the call to the getPostedAttribute() method, passing in the index of the Position field that it requires.
If the Groovy syntax isn't familiar to you in JDeveloper 11g consult Grant Ronald's Introduction to Groovy.
A bad steer here maybe to try and use ADF Groovy's oldValue and newValue methods. Unfortunately these are only available for Groovy expressions in EO Declarative Validators, not in transient attribute.
4) Expose the attribute through the associated View Objects (VO) if necessary.
At runtime you'll note that initially the OldPosition field shows what's in the Position field. When you change the Position field's value, the OldPosition remains at the pre-cached value. Finally on committing the changes to the database, the OldPosition value is overwritten with the new Position value.
For an updated record that has yet been committed to the database, ADF BC stores both the old and new value. Among other reasons ADF BC does this, is it allows the user to cancel any changes, and rather than having to fetch the original value back from the database, ADF BC just retrieves the old value it has cached without a roundtrip to the database.
This cache gives us the ability to solve our original requirements as the ADF BC framework exposes methods to fetch both new and old non committed values from the Entity Object (EO). To fetch the new current value we call the associated accessor such as getPosition() or getName() that was automatically created by the framework in our EntityImpl. To get the old value we use the getPostedAttribute() method passing in the index of the field we wish to fetch.
In JDeveloper 11g through its introduction of Groovy expressions, it's very simple to expose the old value through the Entity Objects:
1) In your required EO create a transient attribute. For example if we want to show the old values for the Position attribute of our EO, we could create a new transient attribute named OldPosition.
2) Ensure the "Persistent" and "Derived from SQL Expression" properties are turned off for the new transient attribute.
3) Set the "Value Type" to Expression and enter the following Groovy expression into the Value field:
adf.object.getPostedAttribute(adf.object.getAttributeIndexOf(model.EmployeesImpl.POSITION))
Note the call to the getPostedAttribute() method, passing in the index of the Position field that it requires.
If the Groovy syntax isn't familiar to you in JDeveloper 11g consult Grant Ronald's Introduction to Groovy.
A bad steer here maybe to try and use ADF Groovy's oldValue and newValue methods. Unfortunately these are only available for Groovy expressions in EO Declarative Validators, not in transient attribute.
4) Expose the attribute through the associated View Objects (VO) if necessary.
At runtime you'll note that initially the OldPosition field shows what's in the Position field. When you change the Position field's value, the OldPosition remains at the pre-cached value. Finally on committing the changes to the database, the OldPosition value is overwritten with the new Position value.
Just how famous can one man get?
Between OOW and the AUSOUG conferences it's a bit of a slow blogging time for me, while presentation preparation takes priority. With a little spare time I thought I'd share this photo of some recent booty (and before you get all excited, that's arrrrgh "Pirate" booty, not the other sort):
On the right my coveted Oracle ACE Director of the Year award from Oracle Magazine. In the middle Duke, thrown from James Gosling himself at his Oracle Develop OOW session. And on the left my cherished SAGE Computing Services award.
If the writing is a little hard to read, it says:
Sage Computing Services' own Chris "ACE Director of the Year" Muir - "How famous can one man get" Award - For excessive hard work blogging and general geeky behaviour.
And to think, I thought nobody noticed ;-)
On the right my coveted Oracle ACE Director of the Year award from Oracle Magazine. In the middle Duke, thrown from James Gosling himself at his Oracle Develop OOW session. And on the left my cherished SAGE Computing Services award.
If the writing is a little hard to read, it says:
Sage Computing Services' own Chris "ACE Director of the Year" Muir - "How famous can one man get" Award - For excessive hard work blogging and general geeky behaviour.
And to think, I thought nobody noticed ;-)
ODTUG down under – more ACEs than a pack of cards
Regular readers already know that ODTUG in conjunction with Oracle Technology Network has invited a number of Oracle ACEs and ACE Directors to present down under. ODTUG has teamed with AUSOUG to give these world recognized presenters (in fact in all cases world award winning speakers) full day slots at the conference that starts next week:
Tim Hall
Lucas Jellema
Peter Koletzke
Connor McDonald
Penny Cookson
Unusually for these presentations, rather than a 45m technical hit, these speakers will be running full day slots, meaning it's a mini training day increasing your value from the conference.
The Perth conference starts next week November 10th & llth, and the Melbourne conference follows 16th & 17th of November. You don't have much time to book so hit the AUSOUG website now for instructions on how to buy tickets.
In addition I'll be presenting my two presentations fresh from OOW09:
SOA Lite: A taste of SOA with a smidgen of Web Services
Oracle JDeveloper 11g JAX-WS Web Services: As easy as 1-2-3: XSD, WSDL, Generate!
...but given these other great speakers are in town, I expect me and my Mum in mine :-(
AUSOUG charges considerably under industry rates for the conference series per delegate, and there are rumours this will be the last year at such cheap rates, so make effort to grab tickets now.
Remember to support your user group like it supports you.
Part II - Working with WLS 10.3.1 SQLAuthenticator password algorithms
In the previous post we looked at how to configure the SQLAuthenticator password encryption options. Among other encryption algorithms we discovered that on creating a user from the WLS console, WLS would create the associated user in a database table with password "password" encrypted to:
{SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
...when the SHA-1 option was set.
As was mentioned in the previous post, as the database table with its users and passwords may be shared by non-WLS based applications, it's important that those systems can encrypt passwords and compare them to the WLS result. In other words, in the example above, given that WLS generated a SHA-1 encrypted password, if another system uses the same SHA-1 algorithm will it generate the same encrypted password allowing it to compare the database SHA-1 encrypted password against the SHA-1 encrypted password it has?
In order to check we can get the same encrypted results, we'll investigate generating a SHA-1 password using the Oracle database's encryption facilities (so in this case the database acts as the other subsystem), comparing the database's encrypted SHA-1 password to that of WLS.
The following solution owes thanks to Sean at Oracle Support who very patiently led me in the right direction with my findings.
dbms_crypto
Oracle database fans will be familiar with the dbms_crypto package that provides encryption support.
dbms_crypto allows us to generate an encrypted password that we can compare to the WLS result. From table 34-1 of the dbms_crypto link, we note that dbms_crypto supports the following one-way hash algorithms: SHA-1, MD4 and MD5. As WLS via the JCE extensions (see the previous post) supports SHA-1, MD2 and MD5, it's fortunate we picked SHA-1 for this example.
The following anonymous PL/SQL block shows an example using the dbms_crypto package hash function with SHA-1 to produce an encrypted result:
The missing bit of information (that I haven't found documented) is that WLS after encrypting the plaintext password, as confirmed by Oracle Support, WLS then converts the output to base 64. In the case of the dbms_crypto hash function, it converts the encrypted result to Hex. In order to get the same result you need to convert the Hex output to base 64.
There's a number of different ways to do this. One is to use a Java routine in the database, converting the dbms_crypto Hex result to a byte array, then byte array to base 64. A suitable algorithm would be:
The end result is: W6ph5Mm5Pz8GgiULbPgzG37mj9g= ... finally matching what WLS wrote to the database (missing the algorithm prefix of course).
Conclusion
Why the WebLogic Server's SQLAuthenticator can make use of different encryption algorithm when writing to the database, it's important to ensure that the results are expected and understood and can be used by other subsystems.
{SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
...when the SHA-1 option was set.
As was mentioned in the previous post, as the database table with its users and passwords may be shared by non-WLS based applications, it's important that those systems can encrypt passwords and compare them to the WLS result. In other words, in the example above, given that WLS generated a SHA-1 encrypted password, if another system uses the same SHA-1 algorithm will it generate the same encrypted password allowing it to compare the database SHA-1 encrypted password against the SHA-1 encrypted password it has?
In order to check we can get the same encrypted results, we'll investigate generating a SHA-1 password using the Oracle database's encryption facilities (so in this case the database acts as the other subsystem), comparing the database's encrypted SHA-1 password to that of WLS.
The following solution owes thanks to Sean at Oracle Support who very patiently led me in the right direction with my findings.
dbms_crypto
Oracle database fans will be familiar with the dbms_crypto package that provides encryption support.
dbms_crypto allows us to generate an encrypted password that we can compare to the WLS result. From table 34-1 of the dbms_crypto link, we note that dbms_crypto supports the following one-way hash algorithms: SHA-1, MD4 and MD5. As WLS via the JCE extensions (see the previous post) supports SHA-1, MD2 and MD5, it's fortunate we picked SHA-1 for this example.
The following anonymous PL/SQL block shows an example using the dbms_crypto package hash function with SHA-1 to produce an encrypted result:
Note the output, a hex value, and doesn't match our WLS output for the same plaintext password "password" encrypted with SHA-1.
DECLARE
input_string VARCHAR2(8);
raw_input RAW(128);
encrypted_raw RAW(2048);
BEGIN
input_string := 'password';
raw_input := utl_raw.cast_to_raw(convert(input_string, 'AL32UTF8','US7ASCII'));
encrypted_raw := dbms_crypto.hash(src => raw_input, typ => dbms_crypto.hash_sh1);
dbms_output.put_line('Output: ' || encrypted_raw);
END;
/
Output: 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
The missing bit of information (that I haven't found documented) is that WLS after encrypting the plaintext password, as confirmed by Oracle Support, WLS then converts the output to base 64. In the case of the dbms_crypto hash function, it converts the encrypted result to Hex. In order to get the same result you need to convert the Hex output to base 64.
There's a number of different ways to do this. One is to use a Java routine in the database, converting the dbms_crypto Hex result to a byte array, then byte array to base 64. A suitable algorithm would be:
...where the hexStringToByteArray function is borrowed from Dave L on StackOverflow.
byte[] bytearray = hexStringToByteArray("5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8");
String base64encoded = new BASE64Encoder().encodeBuffer(bytearray);
The end result is: W6ph5Mm5Pz8GgiULbPgzG37mj9g= ... finally matching what WLS wrote to the database (missing the algorithm prefix of course).
Conclusion
Why the WebLogic Server's SQLAuthenticator can make use of different encryption algorithm when writing to the database, it's important to ensure that the results are expected and understood and can be used by other subsystems.
My OOW presentations - part II
My 2 presentations for OOW are now available for download from the SAGE Computing Services website here:
SOA Lite: A taste of SOA with a smidgen of Web Services
Oracle JDeveloper 11g JAX-WS Web Services: As easy as 1-2-3: XSD, WSDL, Generate!
SOA Lite: A taste of SOA with a smidgen of Web Services
Oracle JDeveloper 11g JAX-WS Web Services: As easy as 1-2-3: XSD, WSDL, Generate!
My OOW presentations
If you're heading to OOW and would love to hear my Aussie accent, my sessions are:
SOA Lite: A taste of SOA with a smidgen of Web Services
S312176 - Sunday 13:00 - 14:00 - Moscone West L3 Room 3000
Abstract: Attempting to gorge yourself on a five-course SOA meal may result in a stomachache and a bill you can least afford at the moment. Instead, a quick and easy recipe with some simple Web services ingredients will give your systems that little taste of SOA you so crave. This session describes why Web services may be a better fit for you than SOA, discusses qualities of contemporary Web services and what skills to focus on when starting out with Web services, and presents a few hints and tips from the Web service trenches.
Oracle JDeveloper 11g JAX-WS Web Services: As easy as 1-2-3: XSD, WSDL, Generate!
307476 - Tuesday 17:30 - 18:30 - Hilton Hotel - Golden Gate 8
Abstract: Web services used to be hard. Creating XML schemas, long-winded Web Services Description Language (WSDL) code, and back-end Java code took much effort. Today Oracle JDeveloper 11g enables developers to visually design both the schemas and WSDL code by drag and drop and generate Web services based on both of these with the latest Java EE JAX-WS/JAXB Web service standards with just a few clicks. Finally programmers can get back to thinking about the programming problem they need to solve without wasting time setting up the Web service artifacts, which can be tedious, error-prone, and very repetitive. Learn more in this session.
In addition we have three ADF Enterprise Methodology Group sessions, one an official session and the other two part of the Unconference:
Oracle ADF Enterprise Methodology Group
312516 - Sunday 10:30 - 11:30 - Moscone West L3 - Room 3014
+ double session Wednesday 13:00 - 15:00 - Moscone West Floor 3 Overlook 1
Abstract: Although Oracle provides leading-edge software to build enterprise applications, there’s more to creating productive teams and delivering successful projects than just the tools. The Oracle ADF Enterprise Methodology Group, formed by Oracle Application Development Framework (Oracle ADF) practitioners around the world to fill that gap, considers wider issues such as best practices, maximizing code reuse, optimizing teamwork, and more. In this session, Oracle JDeveloper and Oracle ADF experts, including Oracle staff and Oracle ACEs, talk about such high-level Oracle ADF considerations. The Oracle ADF Enterprise Methodology Group is meeting at Oracle OpenWorld under the banner of the ODTUG Fusion Middleware SIG for 2009.
I hope to see you at OOW!
SOA Lite: A taste of SOA with a smidgen of Web Services
S312176 - Sunday 13:00 - 14:00 - Moscone West L3 Room 3000
Abstract: Attempting to gorge yourself on a five-course SOA meal may result in a stomachache and a bill you can least afford at the moment. Instead, a quick and easy recipe with some simple Web services ingredients will give your systems that little taste of SOA you so crave. This session describes why Web services may be a better fit for you than SOA, discusses qualities of contemporary Web services and what skills to focus on when starting out with Web services, and presents a few hints and tips from the Web service trenches.
Oracle JDeveloper 11g JAX-WS Web Services: As easy as 1-2-3: XSD, WSDL, Generate!
307476 - Tuesday 17:30 - 18:30 - Hilton Hotel - Golden Gate 8
Abstract: Web services used to be hard. Creating XML schemas, long-winded Web Services Description Language (WSDL) code, and back-end Java code took much effort. Today Oracle JDeveloper 11g enables developers to visually design both the schemas and WSDL code by drag and drop and generate Web services based on both of these with the latest Java EE JAX-WS/JAXB Web service standards with just a few clicks. Finally programmers can get back to thinking about the programming problem they need to solve without wasting time setting up the Web service artifacts, which can be tedious, error-prone, and very repetitive. Learn more in this session.
In addition we have three ADF Enterprise Methodology Group sessions, one an official session and the other two part of the Unconference:
Oracle ADF Enterprise Methodology Group
312516 - Sunday 10:30 - 11:30 - Moscone West L3 - Room 3014
+ double session Wednesday 13:00 - 15:00 - Moscone West Floor 3 Overlook 1
Abstract: Although Oracle provides leading-edge software to build enterprise applications, there’s more to creating productive teams and delivering successful projects than just the tools. The Oracle ADF Enterprise Methodology Group, formed by Oracle Application Development Framework (Oracle ADF) practitioners around the world to fill that gap, considers wider issues such as best practices, maximizing code reuse, optimizing teamwork, and more. In this session, Oracle JDeveloper and Oracle ADF experts, including Oracle staff and Oracle ACEs, talk about such high-level Oracle ADF considerations. The Oracle ADF Enterprise Methodology Group is meeting at Oracle OpenWorld under the banner of the ODTUG Fusion Middleware SIG for 2009.
I hope to see you at OOW!
Part I - Working with WLS 10.3.1 SQLAuthenticator password algorithms
WebLogic Server 10.3.1 supports loading user credentials and roles from a number of different sources, such as LDAP or a database, through the concept of "Security Providers". In order to work with a database table structure a "SQL Authenticator" provider is required.
Edwin Biemond has a good example of setting up both the database table structures and configuring the WLS SQL Authenticator against these tables. To keep the example simple, for the password field in the JHS_USERS table Edwin's has set the SQL Authenticator to write raw plain text passwords to the table. This makes it really easy for demonstration purposes to see what's written to the database.
To extend Edwin's post, a common requirement will be that:
a) The password value is written in an encrypted form to the database
b) Other non-WLS applications can generate the same encrypted result such that the encrypted passwords can be compared
The need for point "a" is obvious, unencrypted password in the database is a security weakness. But what about "b", why would you want this?
For many organisations the list of users and roles will be stored in database tables, and that information will be sourced by many different subsystems implemented in different technologies. It's not uncommon for sites to have Oracle Forms, .Net, JEE (and ADF of course!) applications all relying on the database user tables for their authentication and authorisation information.
Each of these subsystems would require users to login. The subsystem would then encrypt the password, retrieve the corresponding password from the database for the identified user, and compare the results. If they compare, we have a valid user; if the encrypted passwords are different, ring the alarm bells, we have an imposter (or at least make them login again ;-)
All things would be well with this solution, until you throw in the fact that each subsystem may support different encryption algorithms that would produce different results, effectively failing the encrypted password comparison each time. It becomes essential therefore that WLS's SQL Authenticator supports different encryption algorithms in order to provide as much flexibility as possible.
Password Settings
On configuring a SQL Authenticator as per Edwin's example, on accessing the Provider Specific information (from the WLS console select Security Realms -> myrealm -> Providers tab -> your named SQL Authenticator -> Configuration tab -> Provider Specific tab), you'll note the following options that influence the generation of encrypted passwords:
* Plaintext Passwords Enabled – true/false – relates how passwords are read from the database table. If true when WLS retrieves the password from the database, and it encounters a non encrypted password, it will undertake a non encrypted comparison between the user's password who is attempting to login against the database retrieved password. If false, WLS will enforce the database password must be encrypted for it to undertake an encrypted password comparison.
The question arises, how does WLS know the database password is encrypted? The answer is derived from the next detailed property Password Style Retained, where WLS when writing a new encrypted password to the database prefixes the encrypted password with the encryption algorithm that was used to encrypt the password. If it's missing, WLS assumes a plaintext password.
If the Plaintext Passwords Enabled property is false, one other side effect is if you attempt to set the Password Style property to PLAINTEXT, then update a user's password in the database, WLS will throw an error stating it doesn't support PLAINTEXT passwords:
[Security:099063]Plaintext password usage was rejected.
Thanks to Ming at Oracle Support for clarifying this property.
* Password Style Retained – true/false – the following properties unlike the Plaintext Passwords Enabled property deal with when updating existing user passwords in the database table, not when the password is read. When WLS writes a password to the table's password field, along with the encrypted text, it prefixes the password with the password algorithm used wrapped in ellipses. For example if the SHA-1 algorithm is used, the password would look like:
{SHA-1}W6PH5MM5PZ8GGIULBPGZG37MJ9G=
If the Password Style Retained property is set to true, and the existing password has a different encryption algorithm to that specified in the Password Algorithm field, WLS will use the latter to update the password. If Password Style Retained is set to false, regardless, WLS will overwrite the password with that specified in the Password Algorithm field.
* Password Algorithm – text field – default SHA-1 – as per the WLS documentation this can be any Java Cryptography Extension (JCE). Questionably what are the allowable values derived from the JCE? These are listed in the JSE 6.0 Java Cryptography Architecture Standard Algorithm Name Documentation.
For password generation we want a hash (aka. message digest or 1-way encryption) algorithm. From the documentation we find that our options are limited to SHA-1 (the default Password Algorithm value), MD2 and MD5.
Note that the JSE documentation states the bit size of the produced message digest (SHA-1 = 160-bit, MD2 = 128-bit, MD5 = 128-bit), which will influence the size of your password field to store the encrypted database value.
The Password Algorithm can be ignored if the Password Style is PLAINTEXT, or, the Password Style Retained is set to true and the password to be updated does not match the current Password Algorithm's specified function.
* Password Style – PLAINTEXT, HASHED, SALTEDHASHED – as guessed the PLAINTEXT option will write the unencrypted password to the database. A value of HASHED implies the Password Algorithm will be used. SALTEDHASHED also produces encrypted passwords though different from HASHED. I'm currently unsure of the difference between HASHED and SALTEDHASHED, the WLS documentation doesn't differentiate between them, though it does result in a different encrypted value.
Testing
Assuming you've configured your SQL Authenticator correctly as per Edwin's post, let's test what the different settings of the properties do.
For our testing let's assume there's always an existing user ALPHA whose password we want to update, as well as new users BETA, CHARLIE and DELTA (and so on) who we want to create with a new password.
First test
Plaintext Passwords Enabled = true
Password Style Retained = true
Password Algorithm = SHA-1
Password Style = HASHED
For the existing user ALPHA the encrypted password doesn't include the algorithm prefix (ie. {SHA-1}), in fact it was created by some other system that doesn't include the prefix. The ALPHA's password will be updated to "password".
For a new user BETA the password will be set to "password".
First result
Updated user ALPHA password = "password"
For the ALPHA users this result occurs because WLS encounters the Plaintext Passwords Enabled set to true, and the original password stored for the ALPHA user is unencrypted (ie. it's missing the algorithm prefix). WLS therefore decides an update to the password must be a plaintext password update.
New user BETA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
In this case the BETA user makes use of the SHA-1 algorithm.
Second test
Plaintext Passwords Enabled = true
Password Style Retained = false
Password Algorithm = SHA-1
Password Style = HASHED
Same as the last test, for the existing ALPHA user the encrypted password doesn't include the algorithm prefix (ie. {SHA-1}), in fact it was created by some other system that doesn't include the prefix. The ALPHA's password will be updated to "password".
For a new user CHARLIE the password will be set to "password".
Second result
Updated user ALPHA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
New user CHARLIE password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
In this case the Password Style Retained has overwritten the updated user ALPHA's password style with the new SHA-1 algorithm equivalent as the Password Style Retained = false setting removes the original plaintext algorithm – in other words the SHA-1 algorithm takes precedence. As expected the CHARLIE user's passwords uses the SHA-1 algorithm by default.
Third test
In this test we'll use the existing SHA-1 user ALPHA SHA-1 password, while switching to the MD2 algorithm, while not retaining passwords styles:
Plaintext Passwords Enabled = true
Password Style Retained = false
Password Algorithm = MD2
Password Style = HASHED
Existing ALPHA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
For a new user DELTA the password will be set to "password".
Third result
Existing ALPHA password = {MD2}8DiBqIxuORNfDsxg79YJuQ==
New user DELTA password = {MD2}8DiBqIxuORNfDsxg79YJuQ==
As can be seen WLS switches to the MD2 algorithm in both cases as the Password Style Retained = false property enforces this.
Fourth test
In the last test we'll switch back to the SHA-1 algorithm, and attempt to update the ALPHA user's MD2 password to the SHA-1 equivalent asking WLS not to retain the existing password style:
Plaintext Passwords Enabled = true
Password Style Retained = false
Password Algorithm = SHA-1
Password Style = HASHED
Existing ALPHA password = {MD2}8DiBqIxuORNfDsxg79YJuQ==
Fourth result
Existing ALPHA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
As expected the ALPHA user's password is changed from the MD2 to SHA-1 encrypted password, again as the Password Style Retained = false property takes affect.
Conclusion
At this point we've seen how WLS can generate encrypted passwords using different algorithms down to the database. From here it's important to check the encrypted results in the database are actually "standard". In other words if a competing technology uses the SHA-1 algorithm to encrypt a password for example, will it see the same encrypted result WLS produced. This will be addressed in a following post.
Edwin Biemond has a good example of setting up both the database table structures and configuring the WLS SQL Authenticator against these tables. To keep the example simple, for the password field in the JHS_USERS table Edwin's has set the SQL Authenticator to write raw plain text passwords to the table. This makes it really easy for demonstration purposes to see what's written to the database.
To extend Edwin's post, a common requirement will be that:
a) The password value is written in an encrypted form to the database
b) Other non-WLS applications can generate the same encrypted result such that the encrypted passwords can be compared
The need for point "a" is obvious, unencrypted password in the database is a security weakness. But what about "b", why would you want this?
For many organisations the list of users and roles will be stored in database tables, and that information will be sourced by many different subsystems implemented in different technologies. It's not uncommon for sites to have Oracle Forms, .Net, JEE (and ADF of course!) applications all relying on the database user tables for their authentication and authorisation information.
Each of these subsystems would require users to login. The subsystem would then encrypt the password, retrieve the corresponding password from the database for the identified user, and compare the results. If they compare, we have a valid user; if the encrypted passwords are different, ring the alarm bells, we have an imposter (or at least make them login again ;-)
All things would be well with this solution, until you throw in the fact that each subsystem may support different encryption algorithms that would produce different results, effectively failing the encrypted password comparison each time. It becomes essential therefore that WLS's SQL Authenticator supports different encryption algorithms in order to provide as much flexibility as possible.
Password Settings
On configuring a SQL Authenticator as per Edwin's example, on accessing the Provider Specific information (from the WLS console select Security Realms -> myrealm -> Providers tab -> your named SQL Authenticator -> Configuration tab -> Provider Specific tab), you'll note the following options that influence the generation of encrypted passwords:
* Plaintext Passwords Enabled – true/false – relates how passwords are read from the database table. If true when WLS retrieves the password from the database, and it encounters a non encrypted password, it will undertake a non encrypted comparison between the user's password who is attempting to login against the database retrieved password. If false, WLS will enforce the database password must be encrypted for it to undertake an encrypted password comparison.
The question arises, how does WLS know the database password is encrypted? The answer is derived from the next detailed property Password Style Retained, where WLS when writing a new encrypted password to the database prefixes the encrypted password with the encryption algorithm that was used to encrypt the password. If it's missing, WLS assumes a plaintext password.
If the Plaintext Passwords Enabled property is false, one other side effect is if you attempt to set the Password Style property to PLAINTEXT, then update a user's password in the database, WLS will throw an error stating it doesn't support PLAINTEXT passwords:
[Security:099063]Plaintext password usage was rejected.
Thanks to Ming at Oracle Support for clarifying this property.
* Password Style Retained – true/false – the following properties unlike the Plaintext Passwords Enabled property deal with when updating existing user passwords in the database table, not when the password is read. When WLS writes a password to the table's password field, along with the encrypted text, it prefixes the password with the password algorithm used wrapped in ellipses. For example if the SHA-1 algorithm is used, the password would look like:
{SHA-1}W6PH5MM5PZ8GGIULBPGZG37MJ9G=
If the Password Style Retained property is set to true, and the existing password has a different encryption algorithm to that specified in the Password Algorithm field, WLS will use the latter to update the password. If Password Style Retained is set to false, regardless, WLS will overwrite the password with that specified in the Password Algorithm field.
* Password Algorithm – text field – default SHA-1 – as per the WLS documentation this can be any Java Cryptography Extension (JCE). Questionably what are the allowable values derived from the JCE? These are listed in the JSE 6.0 Java Cryptography Architecture Standard Algorithm Name Documentation.
For password generation we want a hash (aka. message digest or 1-way encryption) algorithm. From the documentation we find that our options are limited to SHA-1 (the default Password Algorithm value), MD2 and MD5.
Note that the JSE documentation states the bit size of the produced message digest (SHA-1 = 160-bit, MD2 = 128-bit, MD5 = 128-bit), which will influence the size of your password field to store the encrypted database value.
The Password Algorithm can be ignored if the Password Style is PLAINTEXT, or, the Password Style Retained is set to true and the password to be updated does not match the current Password Algorithm's specified function.
* Password Style – PLAINTEXT, HASHED, SALTEDHASHED – as guessed the PLAINTEXT option will write the unencrypted password to the database. A value of HASHED implies the Password Algorithm will be used. SALTEDHASHED also produces encrypted passwords though different from HASHED. I'm currently unsure of the difference between HASHED and SALTEDHASHED, the WLS documentation doesn't differentiate between them, though it does result in a different encrypted value.
Testing
Assuming you've configured your SQL Authenticator correctly as per Edwin's post, let's test what the different settings of the properties do.
For our testing let's assume there's always an existing user ALPHA whose password we want to update, as well as new users BETA, CHARLIE and DELTA (and so on) who we want to create with a new password.
First test
Plaintext Passwords Enabled = true
Password Style Retained = true
Password Algorithm = SHA-1
Password Style = HASHED
For the existing user ALPHA the encrypted password doesn't include the algorithm prefix (ie. {SHA-1}), in fact it was created by some other system that doesn't include the prefix. The ALPHA's password will be updated to "password".
For a new user BETA the password will be set to "password".
First result
Updated user ALPHA password = "password"
For the ALPHA users this result occurs because WLS encounters the Plaintext Passwords Enabled set to true, and the original password stored for the ALPHA user is unencrypted (ie. it's missing the algorithm prefix). WLS therefore decides an update to the password must be a plaintext password update.
New user BETA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
In this case the BETA user makes use of the SHA-1 algorithm.
Second test
Plaintext Passwords Enabled = true
Password Style Retained = false
Password Algorithm = SHA-1
Password Style = HASHED
Same as the last test, for the existing ALPHA user the encrypted password doesn't include the algorithm prefix (ie. {SHA-1}), in fact it was created by some other system that doesn't include the prefix. The ALPHA's password will be updated to "password".
For a new user CHARLIE the password will be set to "password".
Second result
Updated user ALPHA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
New user CHARLIE password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
In this case the Password Style Retained has overwritten the updated user ALPHA's password style with the new SHA-1 algorithm equivalent as the Password Style Retained = false setting removes the original plaintext algorithm – in other words the SHA-1 algorithm takes precedence. As expected the CHARLIE user's passwords uses the SHA-1 algorithm by default.
Third test
In this test we'll use the existing SHA-1 user ALPHA SHA-1 password, while switching to the MD2 algorithm, while not retaining passwords styles:
Plaintext Passwords Enabled = true
Password Style Retained = false
Password Algorithm = MD2
Password Style = HASHED
Existing ALPHA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
For a new user DELTA the password will be set to "password".
Third result
Existing ALPHA password = {MD2}8DiBqIxuORNfDsxg79YJuQ==
New user DELTA password = {MD2}8DiBqIxuORNfDsxg79YJuQ==
As can be seen WLS switches to the MD2 algorithm in both cases as the Password Style Retained = false property enforces this.
Fourth test
In the last test we'll switch back to the SHA-1 algorithm, and attempt to update the ALPHA user's MD2 password to the SHA-1 equivalent asking WLS not to retain the existing password style:
Plaintext Passwords Enabled = true
Password Style Retained = false
Password Algorithm = SHA-1
Password Style = HASHED
Existing ALPHA password = {MD2}8DiBqIxuORNfDsxg79YJuQ==
Fourth result
Existing ALPHA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
As expected the ALPHA user's password is changed from the MD2 to SHA-1 encrypted password, again as the Password Style Retained = false property takes affect.
Conclusion
At this point we've seen how WLS can generate encrypted passwords using different algorithms down to the database. From here it's important to check the encrypted results in the database are actually "standard". In other words if a competing technology uses the SHA-1 algorithm to encrypt a password for example, will it see the same encrypted result WLS produced. This will be addressed in a following post.
Where real ADF developers meet - OOW09 ADF EMG
Once again the ADF Enterprise Methodology Group is meeting at Oracle Open World to discuss JDeveloper and ADF, and we invite you to join us. This year Simon Haslam has taken the reins and delivered not 1 but 3 sessions at OOW which is an impressive effort.
Of particular interest to me is the "Show me yours!" session where ADF experts will be showing their production level ADF applications, essentially JDeveloper applications in the wild! We encourage you to join us, if not to show and tell, to just hear discussions among ADF experts on what challenges and solutions they're working with each day in the ADF market.
Can't make OOW this year but really want to attend ADF EMG? Are you attending the upcoming UKOUG conference instead? ADF EMG is going international this year, after our success at the ODTUG conference session in the excellent hands of Nathalie Roman, then OOW in October, we're happy to announce we'll be running a session at the UKOUG conference too. Watch this space for more information soon!
Of particular interest to me is the "Show me yours!" session where ADF experts will be showing their production level ADF applications, essentially JDeveloper applications in the wild! We encourage you to join us, if not to show and tell, to just hear discussions among ADF experts on what challenges and solutions they're working with each day in the ADF market.
Can't make OOW this year but really want to attend ADF EMG? Are you attending the upcoming UKOUG conference instead? ADF EMG is going international this year, after our success at the ODTUG conference session in the excellent hands of Nathalie Roman, then OOW in October, we're happy to announce we'll be running a session at the UKOUG conference too. Watch this space for more information soon!
Blatant advert: Yes, we still do Oracle Forms development and training
Blatant plug for SAGE Computing Services. Avert your eyes now if you're not interested in the advert.
I was again asked today by a fellow Oracle professional, as we at SAGE present and blog on the latest JDeveloper and APEX technologies among others, does that mean we've dropped Oracle Forms development and teaching our Oracle Forms training course in Australia altogether?
Not at all. Oracle Forms is still a primary area of development for us and many of our customers, and our Oracle Forms training course has been updated every version since 4.5 to 10g, and soon to be Oracle Forms 11g. While our staff have interest in newer technologies, Forms will remain a skillset we'll maintain into the future, as Forms is pivotal to the success of our clients.
Our Oracle Forms training course, as long as our other Australian Oracle training courses can be found on our website.
I was again asked today by a fellow Oracle professional, as we at SAGE present and blog on the latest JDeveloper and APEX technologies among others, does that mean we've dropped Oracle Forms development and teaching our Oracle Forms training course in Australia altogether?
Not at all. Oracle Forms is still a primary area of development for us and many of our customers, and our Oracle Forms training course has been updated every version since 4.5 to 10g, and soon to be Oracle Forms 11g. While our staff have interest in newer technologies, Forms will remain a skillset we'll maintain into the future, as Forms is pivotal to the success of our clients.
Our Oracle Forms training course, as long as our other Australian Oracle training courses can be found on our website.
Another Aussie Oracle blogger - Scott Wesley
Did I already post/tweet/email about Scott and his blog somewhere? I forgot. In the rush up to Oracle Open World, and moving house, I'm losing track big time of what I've done and haven't done. If I turn up to OOW without any pants you'll know why.
Anyhow, Scott Wesley, a fellow SAGE-ite, has taken up the Oracle blog reins, and can be found at Triangle Circle Square. Scott's one of the team's ninja consultants and Oracle trainers, defender of all things Oracle, except JDeveloper it seems, which makes me highly suspicious. Scott's current blog focus is SQL features, which seems oh-so-persistant-store-to-me. However I'm sure the SQL keen among you will enjoy his posts.
For the user groups out there, like much of the SAGE team, Scott is happy to present to your members. Drop us an email to arrange.
Anyhow, Scott Wesley, a fellow SAGE-ite, has taken up the Oracle blog reins, and can be found at Triangle Circle Square. Scott's one of the team's ninja consultants and Oracle trainers, defender of all things Oracle, except JDeveloper it seems, which makes me highly suspicious. Scott's current blog focus is SQL features, which seems oh-so-persistant-store-to-me. However I'm sure the SQL keen among you will enjoy his posts.
For the user groups out there, like much of the SAGE team, Scott is happy to present to your members. Drop us an email to arrange.
WebLogic Server - identity vs trust keystores
In computing most technologies have lots of terms and acronyms to learn, it's par for the course, you get used to it. However in computer security the frustration is multiplied as there are often many different terms that mean the same thing. It makes implementing security hard, because understanding it is hard, and I'm not surprised why security is considered badly implemented because the average Joe will struggle (and for the record I'm the average Chris so I struggle too ;-).
I've been trying recently to get straight in my head what is stored in the WLS identity and trust keystores, and what the difference between identity and trust is anyhow. Thanks to kind assistance from Gerard Davison, I think I can now post my understandings, and as usual, hopefully the post is helpful to other readers. As noted however security to me is a difficult area, and so be sure to check the facts here, your mileage with this post may vary.
The following WLS documentation attempts to explain the concepts of identity and trust:
http://download.oracle.com/docs/cd/E12839_01/web.1111/e13707/identity_trust.htm#i1170342
...in ripping out one of the core paragraphs, with a slight rewrite of my own we can see the concept of identity, and how it relates to the public and private keys:
"The public key is embedded in a digital certificate with additional information describing the owner of the public key, such as name, street address, and e-mail address *as well as the hostname*. *Along with this the digital certificate containing the public key, and the separate related private key, provide identity for the server*."
...ultimately to identify the server, to assert the server is who the server says it is.
The digital certificate containing the public key is also referred to as the "server certificate", as for example in 1-way-SSL traffic between the server and client, the server certificate containing the public key is what is initially passed to the client.
There is a missing piece in the puzzle. Regardless that the digital certificate states the owner of the public key, their name and so on, how does a client know that the "identity" asserted by the digital certificate is true? That's where Certificate Authorities (CAs) come in.
Ignoring self signed digital certificates, a typical digital certificate used on the internet containing the public key and owner details is signed by a trusted CA who has verified the identity of the owner. Presumably when purchasing digital certificates from CAs, this is what some of the cost covers, the CAs research into ensuring that the identity details embedded in the digital cert are actually true.
At runtime on receiving the digital certificate, the client checks the CA and if the CA is one that the client trusts (or a CA in a chain of trusted CAs), then the identity of the server is established/verified.
Thus the "identity" of the server is established by what's stored in the "identity" keystore, and its contents are what are farmed out to clients establishing secure connections with the server, who then verify the supplied digital certificate's CA against the clients own list of trusted CAs. The "identity keystore" is also referred to as the "server keystore", because it establishes the server's identity (ie. I am who I say I am).
WLS side note: As mentioned the digital certificate also includes the host name of the server, or in other words the digital certificate is pegged to that server and that server alone. This implies on that server with its relating digital certificate, *all* of the applications will share that single digital certificate for secure communications. Occasionally a requirement will arise where each application must have its own digital certificate. In WLS because keystores are configured under an individual WLS "managed server", if you have two separate applications, it is not possible to use separate digital certificates for each in one managed server. The solution is to create another managed server with its own keystores.
WLS web service side note: Following on from the previous side note, for web services that use in-message encryption and digital signatures, there is often the requirement for multiple different digital certificates. Under WLS to provision the WS-Security model, WLS has a separate Web Service Security Configuration (WSSC) to provision this setup.
Finally regarding the trust keystore, what is its job in all of this? The trust keystore is typically used for storing CA digital certificates, essentially the CAs who will be used to check any digital certificates that are given to the server at runtime (just the same as the client did above). In the standard 1-way-SSL between a client and the WLS server, the trust keystore doesn't come into the equation as the client has its own trust keystore (containing the CAs) and the server has nothing to verify. Yet in the case of mutual SSL (aka. 2 way SSL) between the client and server, the client and server actually swap each other digital certificates to establish identity of both parties, and in this case the server must be able to test the identity of the client through the CA of the client's digital certificate.
Mutual SSL side note: the setup of mutual SSL is more complicated than this. Readers are advised to refer to the following Oracle article.
Final author's note: if any readers find anything particularly wrong with the ideas presented in this post I'd be keen to hear them please. As I've really only experience with 1-way-SSL, it's hard to know if what I've said applies to the concepts of mutual SSL and other security configurations.
I've been trying recently to get straight in my head what is stored in the WLS identity and trust keystores, and what the difference between identity and trust is anyhow. Thanks to kind assistance from Gerard Davison, I think I can now post my understandings, and as usual, hopefully the post is helpful to other readers. As noted however security to me is a difficult area, and so be sure to check the facts here, your mileage with this post may vary.
The following WLS documentation attempts to explain the concepts of identity and trust:
http://download.oracle.com/docs/cd/E12839_01/web.1111/e13707/identity_trust.htm#i1170342
...in ripping out one of the core paragraphs, with a slight rewrite of my own we can see the concept of identity, and how it relates to the public and private keys:
"The public key is embedded in a digital certificate with additional information describing the owner of the public key, such as name, street address, and e-mail address *as well as the hostname*. *Along with this the digital certificate containing the public key, and the separate related private key, provide identity for the server*."
...ultimately to identify the server, to assert the server is who the server says it is.
The digital certificate containing the public key is also referred to as the "server certificate", as for example in 1-way-SSL traffic between the server and client, the server certificate containing the public key is what is initially passed to the client.
There is a missing piece in the puzzle. Regardless that the digital certificate states the owner of the public key, their name and so on, how does a client know that the "identity" asserted by the digital certificate is true? That's where Certificate Authorities (CAs) come in.
Ignoring self signed digital certificates, a typical digital certificate used on the internet containing the public key and owner details is signed by a trusted CA who has verified the identity of the owner. Presumably when purchasing digital certificates from CAs, this is what some of the cost covers, the CAs research into ensuring that the identity details embedded in the digital cert are actually true.
At runtime on receiving the digital certificate, the client checks the CA and if the CA is one that the client trusts (or a CA in a chain of trusted CAs), then the identity of the server is established/verified.
Thus the "identity" of the server is established by what's stored in the "identity" keystore, and its contents are what are farmed out to clients establishing secure connections with the server, who then verify the supplied digital certificate's CA against the clients own list of trusted CAs. The "identity keystore" is also referred to as the "server keystore", because it establishes the server's identity (ie. I am who I say I am).
WLS side note: As mentioned the digital certificate also includes the host name of the server, or in other words the digital certificate is pegged to that server and that server alone. This implies on that server with its relating digital certificate, *all* of the applications will share that single digital certificate for secure communications. Occasionally a requirement will arise where each application must have its own digital certificate. In WLS because keystores are configured under an individual WLS "managed server", if you have two separate applications, it is not possible to use separate digital certificates for each in one managed server. The solution is to create another managed server with its own keystores.
WLS web service side note: Following on from the previous side note, for web services that use in-message encryption and digital signatures, there is often the requirement for multiple different digital certificates. Under WLS to provision the WS-Security model, WLS has a separate Web Service Security Configuration (WSSC) to provision this setup.
Finally regarding the trust keystore, what is its job in all of this? The trust keystore is typically used for storing CA digital certificates, essentially the CAs who will be used to check any digital certificates that are given to the server at runtime (just the same as the client did above). In the standard 1-way-SSL between a client and the WLS server, the trust keystore doesn't come into the equation as the client has its own trust keystore (containing the CAs) and the server has nothing to verify. Yet in the case of mutual SSL (aka. 2 way SSL) between the client and server, the client and server actually swap each other digital certificates to establish identity of both parties, and in this case the server must be able to test the identity of the client through the CA of the client's digital certificate.
Mutual SSL side note: the setup of mutual SSL is more complicated than this. Readers are advised to refer to the following Oracle article.
Final author's note: if any readers find anything particularly wrong with the ideas presented in this post I'd be keen to hear them please. As I've really only experience with 1-way-SSL, it's hard to know if what I've said applies to the concepts of mutual SSL and other security configurations.
JDev 11gR1 - af:tree mashup – using hierarchical tables and drag n drop
This blog post demonstrates creating an ADF Faces RC af:tree component that sources its data from a hierarchical database table, and supports drag n drop of the nodes.
Both these topics have been discussed and demonstrated by other excellent bloggers, the core of this post is to bring both concepts together, with my usual own proof of concept documentation that may be useful to readers.
The ADF Faces RC support for hierarchical data sources was defined by Chandu Bhavsar.
The drag and drop support for af:trees was documented by Luc Bors.
(Definitely the kudos for this post must go to both Chandu and Luc for their posts that sparked the inspiration for mine)
Data model
In this example we'll use the following table:
The data:
This details the steps to setup an ADF BC layer and ADF Faces RC bindings to support the af:tree with hierachical data from the organisations table, as previously described in Chandu Bhavsar post.
Note the following steps are well documented on Chandu's post, though you will find slightly more detail on creating the correct bindings below:
1) Create a Fusion Web App with an ADF BC Model project and ADF Faces RC ViewController.
Model project
2) In the Model project create an empty Application Module (AM)
3) Create an Entity Object (EO) based on your organisations table in the database.
4) Create two View Objects (VO) based off the same EM. Name the first ParentOrgView and the second LeafOrgView.
5) Modify the ParentOrgView query as follows:
Essentially:
ParentOrgView.OrgId = LeafOrgView.ParentOrgId
8) Create a second VO Link between the LeafOrgView to itself as follows:
Essentially:
LeafOrgView (source).OrgId = LeafOrgView (dest).ParentOrgId
9) Externalize the VOs through the AM using the following model:
Essentially:
ParentOrgView1
- LeafOrgView1
- - LeafOrgView2
ViewController project
10) In your ViewController project create a new blank JSF page called treeMashupDemo.jspx.
11) From the Data Control Palette drag the ParentOrgView onto the page as a tree. In the Edit Tree Binding you should see the following:
Note the first level of the tree has been defined as model.ParentOrgView.
12) For clarity when testing later, ensure both the OrgId and Name are included in the Display Attributes.
13) With the model.ParentOrgView node selected in the Tree Level Rules, select the green plus (+) button and select LeafOrgView:
14) With the LeafOrgView node selected in the Tree Level Rules, ensure both the OrgId and Name are included in the Display Attributes.
15) Again with the LeafOrgView node selected in the Tree Level Rules, again select the green plus (+) button, and select LeafOrgView__2:
Note how the Tree Level Rules only has 2 nodes, but to the right of each node is the child of the current node. Of specific interest in the hierarchical relationship between LeafOrgView and LeafOrgView__2.
16) For reference the JSF af:tree code is as follows:
..and the page def XML file as follows:
Testing
On running our web page we see the following:
Note that the tree is happily showing the hierarchical data based on our tree bindings.
Adding drag n drop to the tree
The next set of functionality we wish to add is the ability to drag and drop nodes, or in our case organisations, in the tree. This involves adding support for drag n drop to the tree, as well as behind the scenes updating the dropped organisation's parent_org_id to that of the org_id of the organisation the original was dropped on.
The inspiration of this section comes from Luc Bors blog post, with slight difference in mine some of the supporting code is further spelt out:
1) As a reminder at the moment our af:tree code looks as follows:
3) In your adfc-config.xml file declare a bean treeBean of class view.TreeBean:
4) And create a Java class TreeBean in your view package within the ViewController project.
5) Create an AppModuleImpl for the AM
6) Create a LeafOrgViewImpl for the VO
7) Create a LeafOrgViewRowImpl for the VO and ensure to include the accessors
8) In the AM expose the LeafOrgView VO one more time as its own node (not a child), and call the usage LeafOrgViewAll as follows:
9) Finally the dragAndDrop code is as follows. Note the code includes inline documentation comments that explains what is occurring:
This does pose a problem, because while during testing it's fine to show the OrgId and Name of the organisations in the tree, for production we might not want to show these meaningless internal ID numbers to the user. The simple fix for this is to return to the af:tree and update the af:outputText component who is responsible for what values to show for each node in the tree, changing the EL expression from #{code} to #{code.Name}:
Both these topics have been discussed and demonstrated by other excellent bloggers, the core of this post is to bring both concepts together, with my usual own proof of concept documentation that may be useful to readers.
The ADF Faces RC support for hierarchical data sources was defined by Chandu Bhavsar.
The drag and drop support for af:trees was documented by Luc Bors.
(Definitely the kudos for this post must go to both Chandu and Luc for their posts that sparked the inspiration for mine)
Data model
In this example we'll use the following table:
CREATE TABLE organisationsNote the FK between the table and itself, essentially modelling that an organisation has sub-organisations (or agencies).
(org_id NUMBER(4,0) NOT NULL
,parent_org_id NUMBER(4,0)
,name VARCHAR2(35) NOT NULL
,CONSTRAINT org_pk PRIMARY KEY (org_id)
,CONSTRAINT org_parent_fk
FOREIGN KEY (parent_org_id)
REFERENCES organisations (org_id));
The data:
ORG_ID PARENT_ORG_ID NAMEHierarchical af:tree
------ ------------- -------------------------------
1000 (null) Sage Computing Services
1010 1000 Training Division
1030 1010 Self Study Program
1040 1010 Classroom Training
2264 (null) Australian Medical Systems
3210 (null) Conservation Society
3214 3210 Forests Division
3216 3210 Rivers Division
4394 (null) Newface cosmetics
3842 (null) Institute of Business Services
3843 3842 Marketing Services
3844 3842 Financial Services
This details the steps to setup an ADF BC layer and ADF Faces RC bindings to support the af:tree with hierachical data from the organisations table, as previously described in Chandu Bhavsar post.
Note the following steps are well documented on Chandu's post, though you will find slightly more detail on creating the correct bindings below:
1) Create a Fusion Web App with an ADF BC Model project and ADF Faces RC ViewController.
Model project
2) In the Model project create an empty Application Module (AM)
3) Create an Entity Object (EO) based on your organisations table in the database.
4) Create two View Objects (VO) based off the same EM. Name the first ParentOrgView and the second LeafOrgView.
5) Modify the ParentOrgView query as follows:
SELECT Organisations.ORG_ID,6) You don't need to modify the LeafOrgView query. For completeness it's described as follows:
Organisations.PARENT_ORG_ID,
Organisations.NAME
FROM ORGANISATIONS Organisations
WHERE Organisations.PARENT_ORG_ID IS NULL
SELECT Organisations.ORG_ID,7) Create a VO Link between the ParentOrgView and LeafOrgView as follows:
Organisations.PARENT_ORG_ID,
Organisations.NAME
FROM ORGANISATIONS Organisations
Essentially:ParentOrgView.OrgId = LeafOrgView.ParentOrgId
8) Create a second VO Link between the LeafOrgView to itself as follows:
Essentially:LeafOrgView (source).OrgId = LeafOrgView (dest).ParentOrgId
9) Externalize the VOs through the AM using the following model:
Essentially:ParentOrgView1
- LeafOrgView1
- - LeafOrgView2
ViewController project
10) In your ViewController project create a new blank JSF page called treeMashupDemo.jspx.
11) From the Data Control Palette drag the ParentOrgView onto the page as a tree. In the Edit Tree Binding you should see the following:
Note the first level of the tree has been defined as model.ParentOrgView.12) For clarity when testing later, ensure both the OrgId and Name are included in the Display Attributes.
13) With the model.ParentOrgView node selected in the Tree Level Rules, select the green plus (+) button and select LeafOrgView:
14) With the LeafOrgView node selected in the Tree Level Rules, ensure both the OrgId and Name are included in the Display Attributes.
15) Again with the LeafOrgView node selected in the Tree Level Rules, again select the green plus (+) button, and select LeafOrgView__2:
Note how the Tree Level Rules only has 2 nodes, but to the right of each node is the child of the current node. Of specific interest in the hierarchical relationship between LeafOrgView and LeafOrgView__2.16) For reference the JSF af:tree code is as follows:
var="node"...the bindings look as follows:
selectionListener="#{bindings.ParentOrgView1.treeModel.makeCurrent}"
rowSelection="single"
id="t1">
..and the page def XML file as follows:<?xml version="1.0" encoding="UTF-8" ?>
Package="view.pageDefs">
Testing
On running our web page we see the following:
Note that the tree is happily showing the hierarchical data based on our tree bindings.Adding drag n drop to the tree
The next set of functionality we wish to add is the ability to drag and drop nodes, or in our case organisations, in the tree. This involves adding support for drag n drop to the tree, as well as behind the scenes updating the dropped organisation's parent_org_id to that of the org_id of the organisation the original was dropped on.
The inspiration of this section comes from Luc Bors blog post, with slight difference in mine some of the supporting code is further spelt out:
1) As a reminder at the moment our af:tree code looks as follows:
var="node"2) We then introduce a collectionDragSource and a collectionDropTarget to support the drag and drop within the tree:
selectionListener="#{bindings.ParentOrgView1.treeModel.makeCurrent}"
rowSelection="single"
id="t1">
var="node"Note both support the MOVE action, they both specify a matching modelName DnDOrganisations, and finally the dropListener maps to a backing bean method we'll define in a moment. It's essential the modelName's match including the case of the name, and we'll be referring to this in the dragAndDrop backing bean treeBean method in a moment.
selectionListener="#{bindings.ParentOrgView1.treeModel.makeCurrent}"
rowSelection="single"
id="t1">
modelName="DnDOrganisations"/>
modelName="DnDOrganisations"
dropListener="#{treeBean.dragAndDrop}"/>
3) In your adfc-config.xml file declare a bean treeBean of class view.TreeBean:
4) And create a Java class TreeBean in your view package within the ViewController project.
package view;The real work for drag and drop is done in the backing bean method. However in order for the code to work there are a couple of items we need to configure in the Model project:
public class TreeBean {
}
5) Create an AppModuleImpl for the AM
6) Create a LeafOrgViewImpl for the VO
7) Create a LeafOrgViewRowImpl for the VO and ensure to include the accessors
8) In the AM expose the LeafOrgView VO one more time as its own node (not a child), and call the usage LeafOrgViewAll as follows:
9) Finally the dragAndDrop code is as follows. Note the code includes inline documentation comments that explains what is occurring:
package view;You'll note in the code I take pains to mention it's essential the OrgId is one of the displayed attributes for the tree. If you fail to supply this the routine has no OrgId attribute to fetch the OrgId value from.
import model.AppModuleImpl;
import model.LeafOrgViewImpl;
import model.LeafOrgViewRowImpl;
import model.ParentOrgViewRowImpl;
import oracle.adf.model.BindingContext;
import oracle.adf.view.rich.component.rich.data.RichTree;
import oracle.adf.view.rich.datatransfer.DataFlavor;
import oracle.adf.view.rich.datatransfer.Transferable;
import oracle.adf.view.rich.dnd.DnDAction;
import oracle.adf.view.rich.event.DropEvent;
import oracle.adfinternal.view.faces.model.binding.FacesCtrlHierNodeBinding;
import oracle.jbo.Key;
import oracle.jbo.uicli.binding.JUCtrlHierNodeBinding;
import org.apache.myfaces.trinidad.model.CollectionModel;
import org.apache.myfaces.trinidad.model.RowKeySet;
public class TreeBean {
public DnDAction dragAndDrop(DropEvent dropEvent) {
// The default action - do nothing
DnDAction result = DnDAction.NONE;
// Represents the object that was dropped
Transferable draggedTransferObject = dropEvent.getTransferable();
// The data in the draggedTransferObject "Transferrable" object is the row key for the dragged component.
// Note how the DnDOrganisations value in the call to getDataFlavor() matches the collectionDragSource
// and collectionDropTarget tags model attributes in our page. It's essential the strings exactly match.
DataFlavor draggedRowKeySetFlavor = DataFlavor.getDataFlavor(RowKeySet.class, "DnDOrganisations");
RowKeySet draggedRowKeySet = draggedTransferObject.getData(draggedRowKeySetFlavor);
if (draggedRowKeySet != null) {
// We grab the tree's data model, essentially the CollectionModel that stores the complete tree of nodes
CollectionModel treeModel = draggedTransferObject.getData(CollectionModel.class);
// Ask the collection model to set the current row/node to that of the transferrable object that was dropped
Object draggedKey = draggedRowKeySet.iterator().next();
treeModel.setRowKey(draggedKey);
// Grab that current row (thanks to the last statements work) and get the row's OrgId. It's essential the
// OrgId is one of the displayed attributes in the tree binding.
FacesCtrlHierNodeBinding draggedTreeNode = (FacesCtrlHierNodeBinding)treeModel.getRowData();
oracle.jbo.domain.Number draggedTreeNodeId = (oracle.jbo.domain.Number)draggedTreeNode.getAttribute("OrgId");
// The dropEvent carries the target/location's row key where the dropped organisations was dropped
Object serverRowKey = dropEvent.getDropSite();
RichTree richTree = (RichTree)dropEvent.getDropComponent();
// This time we use the tree itself to make it's current row that of the server row key (ie. the destination)
richTree.setRowKey(serverRowKey);
// And we retrieve that row's index
int rowIndex = richTree.getRowIndex();
// The rich tree based on the index allows us to retrieve that current row/organisation's OrgId
oracle.jbo.domain.Number targetNodeId = (oracle.jbo.domain.Number)((JUCtrlHierNodeBinding)richTree.getRowData(rowIndex)).getAttribute("OrgId");
// At this point we now have the OrgId of the dropped organisation (draggedTreeNodeId) and the OrgId of the
// organisation that is the target. From here we simply want to update the dropped organisations' ParentOrgId
// to the OrgId of the target. This is best done through the model layer.
//
// Normally this would be best done by fetching the appropriate iterator bindings and making the changes through
// the bindings. However in this case the tree doesn't expose any iterator for the leaf nodes, so we need to
// resort to retrieve the Model project's objects and do the work ourself.
// Retrieve the AM and then a handle on the LeafOrgViewAll - this gives us access to all rows regardless of
// where they exist in the hierarchy
AppModuleImpl am = (AppModuleImpl)BindingContext.getCurrent().getDefaultDataControl().getApplicationModule();
LeafOrgViewImpl leafOrgView = (LeafOrgViewImpl)am.getLeafOrgViewAll();
// Given the dragged organisation's OrgId, construct a key object, and then retrieve that row from the VO using
// the key
Object[] nodeObjectKey = new Object[] {draggedTreeNodeId};
Key nodeKey = new Key(nodeObjectKey);
LeafOrgViewRowImpl nodeRow = (LeafOrgViewRowImpl)leafOrgView.getRow(nodeKey);
// See below
boolean parentNode = nodeRow.getParentOrgId() == null;
// Finally update that organisaiton's ParentOrgId to that of the target organisation's OrgId
nodeRow.setParentOrgId(targetNodeId);
// And commit the changes – obviously this has side effects on any other uncommitted data, be careful
am.getDBTransaction().commit();
// If we've moved a parent node to become a leaf, we need to force the parent VO to requery itself to correctly
// reflect the data change. This is destructive on the current expand/collapsed state of the tree.
// I'm not overly sure of a solution for this; maybe a reader can suggest one.
if (parentNode) {
am.getParentOrgView1().clearCache();
am.getParentOrgView1().executeQuery();
}
// Indicate to the dragEvent that the operation was succesful and visually the move should occur in the tree
result = DnDAction.MOVE;
}
return result;
}
}
This does pose a problem, because while during testing it's fine to show the OrgId and Name of the organisations in the tree, for production we might not want to show these meaningless internal ID numbers to the user. The simple fix for this is to return to the af:tree and update the af:outputText component who is responsible for what values to show for each node in the tree, changing the EL expression from #{code} to #{code.Name}:
var="node"This ensures only the name attribute is displayed:
selectionListener="#{bindings.ParentOrgView1.treeModel.makeCurrent}"
rowSelection="single"
id="t1">
modelName="DnDOrganisations"/>
modelName="DnDOrganisations"
dropListener="#{treeBean.dragAndDrop}"/>
Are your libraries targeted to the correct WLS managed server?
Recently we upgraded our Oracle WebLogic Server's from 10.3 to 10.3.1, and coincidentally migrated a JDeveloper ADF application 11g to 11gR1. ADF applications require a set of libraries that must be deployed to WLS before the ADF application can run, of which we completed successfully, or so we thought. This post documents a little trap for new players when configuring WLS and deployed applications.
On deploying our upgraded ADF 11gR1 application to our WLS 10.3.1 server with the updated ADF libraries, we hit an error on deployment from JDev. The logs showed the following results:
This confused us because we could actually see them installed under the deployments tab in the WLS console. However the error in the end was a simple one on our part.
On installing the updated ADF libraries we installed them into the WLS AdminServer managed server. Yet on deploying our application, we chose to deploy the application to a separate WLS managed server called ADFServer (seen in the logs). For the application to find the ADF libraries, they needed to be installed into the ADFServer as well.
To fix this, one option is to head to the WLS console, locate the libraries in the Deployment node, and on selecting each library, under the Targets tab, ensure to allocate the libraries to the correct managed server. Alternatively your other option is to deploy your application to the WLS managed server where the libraries are targeted/installed.
On deploying our upgraded ADF 11gR1 application to our WLS 10.3.1 server with the updated ADF libraries, we hit an error on deployment from JDev. The logs showed the following results:
[08:54:26 AM] ---- Deployment started. ----The last set of errors reveals that the server can't find the libraries that the deployed application are dependent on. To highlight them:
[08:54:26 AM] Target platform is (Weblogic 10.3).
[08:54:39 AM] Entering Target Selection Dialog
[08:54:55 AM] Retrieving existing application information
[08:54:55 AM] Running dependency analysis...
[08:54:55 AM] Building...
[08:54:59 AM] Deploying 4 profiles...
[08:54:59 AM] Wrote Archive Module to C:\JDeveloper\mywork\CR123\trunk\CommonViewController\deploy\CommonViewController.jar
[08:54:59 AM] Wrote Archive Module to C:\JDeveloper\mywork\CR123\trunk\CommonModel\deploy\CommonModel.jar
[08:54:59 AM] Wrote Web Application Module to C:\JDeveloper\mywork\CR123\trunk\ViewController\deploy\App_ViewController.war
[08:55:00 AM] Wrote Enterprise Application Module to C:\JDeveloper\mywork\CR123\trunk\deploy\App_application1.ear
[08:55:04 AM] Deploying Application...
[08:55:06 AM] [Deployer:149191]Operation 'deploy' on application 'App_application1' is initializing on 'ADFServer'
[08:55:06 AM] [Deployer:149193]Operation 'deploy' on application 'App_application1' has failed on 'ADFServer'
[08:55:06 AM] [Deployer:149034]An exception occurred for task [Deployer:149026]deploy application App_application1 on ADFServer.: [J2EE:160149]Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false], [Extension-Name: oracle.jsp.next, exact-match: false]..
[08:55:06 AM] Weblogic Server Exception: weblogic.management.DeploymentException: [J2EE:160149]Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false], [Extension-Name: oracle.jsp.next, exact-match: false].
[08:55:06 AM] See server logs or server console for more details.
[08:55:06 AM] weblogic.management.DeploymentException: [J2EE:160149]Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false], [Extension-Name: oracle.jsp.next, exact-match: false].
[08:55:06 AM] #### Deployment incomplete. ####
[08:55:06 AM] Deployment Failed
[08:55:06 AM] Weblogic Server Exception: weblogic.management.DeploymentException: [J2EE:160149]Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false], [Extension-Name: oracle.jsp.next, exact-match: false].Note how WLS is stating it can't find adf.oracle.domain nor oracle.jsp.next.
[08:55:06 AM] See server logs or server console for more details.
[08:55:06 AM] weblogic.management.DeploymentException: [J2EE:160149]Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false], [Extension-Name: oracle.jsp.next, exact-match: false].
This confused us because we could actually see them installed under the deployments tab in the WLS console. However the error in the end was a simple one on our part.
On installing the updated ADF libraries we installed them into the WLS AdminServer managed server. Yet on deploying our application, we chose to deploy the application to a separate WLS managed server called ADFServer (seen in the logs). For the application to find the ADF libraries, they needed to be installed into the ADFServer as well.
To fix this, one option is to head to the WLS console, locate the libraries in the Deployment node, and on selecting each library, under the Targets tab, ensure to allocate the libraries to the correct managed server. Alternatively your other option is to deploy your application to the WLS managed server where the libraries are targeted/installed.
One-Way SSL with JAX-WS using JDeveloper 11gR1 and WLS 10.3.1
A while back Gerard Davison blogged some simple examples of using WS-Security Policies. Gerard's specific example dealt with the WLS policy Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256.xml. As Gerard notes the said policy (further documented in the WLS 10.3.1 doco here) implements user name tokens, encryption of the tokens and signing of the whole SOAP payload.
The following post strips back Gerard's example to instead to consider the steps in setting up and testing One-Way SSL for a JAX-WS web service generated via JDeveloper 11gR1 and installed in WLS 10.3.1, using the WLS policy Wssp1.2-2007-Https.xml.
Assumptions
This article assumes the reader has the following basic knowledge:
* HTTPS/SSL
* Digital certificates and trusted/certificate authorities (CAs)
* Oracle's WebLogic Server, WLS managed servers and the WLS console
One-Way SSL vs Two-Way SSL
For those not familiar with either, Oracle's WLS documentation has a good explanation of the implementation of and differences between One-Way SSL and Two-Way SSL in the Understanding Security for Oracle WebLogic Server manual.
Steps
To implement a One-Way SSL example we'll run through the following steps:
1) Create a basic JAX-WS web service with JDeveloper 11gR1
2) Generate the digital certificates required for the WLS server
3) Modify the web service to use the Wssp1.2-2007-Https.xml WLS policy
4) Deploy the running web service to WLS
5) Test the running web service via JDeveloper's HTTP Analyzer
6) Test the running web service via SoapUI
7) Test the running web service via a JAX-WS client
8) Inspect the web service packets on the wire to verify the traffic is indeed encrypted
1) Create a basic JAX-WS web service with JDeveloper 11gR1
This step is documented in a previous blog post Creating JAX-WS web services via a WSDL in JDev 11g. There are also a number of viewlet demonstrations available from Oracle's OTN which show how to construct the WSDL in a drag'n'drop fashion.
The resulting web service we'll demonstrate here is a very simple one. It is comprised of the following solutions:
OneWaySSLExample.xsd
OneWaySSLExample.wsdl
The overall web service comprises of a single operation accepting the inputElement and outputElement strings as specified in the XSD.
OneWaySSLPortTypeImpl.java
Example request SOAP payload
Example response SOAP payload
2) Generate the digital certificates required for the WLS server
In order for a client to undertake a SSL connection with our web service on the WLS server, the WLS server must be configured with a valid digital certificate.
Again note from the Oracle documentation how One-Way SSL works at runtime:
With one-way SSL authentication, the target (the server) is required to present a digital certificate to the initiator (the client) to prove its identity. The client performs two checks to validate the digital certificate:
1. The client verifies that the certificate is trusted (meaning, it was issued by the client's trusted CA), is valid (not expired), and satisfies the other certificate constraints.
2. The client checks that the certificate Subject's common name (CN) field value matches the host name of the server to which the client is trying to connect
If both of the above checks return true, the SSL connection is established.
In this section we consider the digital certificates required for the WLS server.
WLS is an interesting application server in that it keeps two separate Java keystores, 1 for storing the digital certificates for such actions as SSL, and another which is typically used for storing CA digital certificates. The former is referred to as the identity keystore, the later the trust keystore.
The WLS manual Securing Oracle WebLogic Server section 11 Configuring Identity and Trust has a detailed explanation of this setup.
By default WLS comes with demonstration identity and trust keystores containing demonstration digital certificates. As the WLS documentation takes great pains to explain these are for development purposes only and should never be used in a production environment. For the purposes of this blog post if you're testing One-Way SSL in a development environment you can in fact skip this entire step as the demonstration WLS keystores will suffice.
To check that the demonstration keystores are currently installed login to your WLS console, select your server, and under the Configurations -> Keystores tab you'll see the following entries:
Your entries for the file locations of the keystore will be different from my example here dependent on where you installed WLS.
However using the demonstration keystores avoids the whole learning exercise of configuring your own custom digital certificates in WLS which is an important lesson. The following describes those steps in detail, as based off Gerard's original post.
To install our own digital certificate we followed these general steps:
a) Open a command prompt and set the WLS environment
b) Generate our own trusted certificate authority digital certificate
c) Store the private key and digital certificate and import into the identity keystore
d) Store the same digital certificate into the trust keystore.
e) Configure the new keystores in WLS's identity and trust keystore
The following describes those steps in detail. In order to do this we've used WLS utilities to do as much of the work as possible.
a) Open a command prompt and set the WLS environment
Under Windows open a command prompt on the same machine as where WLS is installed, create a temporary directory in your favourite place and cd to that directory, and run your WLS server's setDomainEnv.cmd command. Something like:
"C:\\setDomainEnv.cmd"
Once run ensure you're still in your new directory.
b) Generate our own trusted certificate authority digital certificate
This generates 4 files: ServerCACert.der, ServerCACert.pem, ServerCAKey.der, ServerCAKey.pem
The utils.CertGen utility is useful for development purposes, but as per the WLS documentation, should not be used for production purposes. Alternatively OpenSSL could be used instead.
Note the use of selfsigned flag. This implies this digital certificate will be used both as the CA in the trust keystore and the served digital certificate in the identity keystore. This is not what we'd do for a production environment using commercial Certificate Authorities, but is sufficient for demonstration purposes in this post.
More information on:
* the WLS CertGen utility can be found here.
* .der vs .pem files can be found here and here.
* WLS provides two utilities der2pem and pem2der can be used to convert between the two file types.
Under Windows you can double click on the ServerCACert.der file to show its contents:
If you have access to the openSSL command line tool you can use it to query the certificate we just created:
This identifies information that maybe useful later if we make a mistake, such as the encryption algorithm used (RSA), the size of the keys (1024bit), the serial number of the certificate (a hex number).
c) Store the private key and the digital certificate in the identity keystore
d) Store the same digital certificate into the trust keystore
Import the certificate generated in step b into a trust keystore.
e) Configure the new keystores in WLS's identity and trust keystore
To configure the keystores in WLS enter the WLS console, select the managed server you're interested in, then make the following changes under the following tabs:
Configuration tab -> General subtab
SSL Listed Port Enabled = checkbox
SSL Listen Port = 7102 (and different from the Listen Port)
Configuration tab -> Keystores subtab
Keystores = Custom Identity and Custom Trust
Custom Identity Keystore = \ServerIdentity.jks, such as c:\temp\ServerIdentity.jks
Custom Identity Keystore Type = jks
Custom Identity Keystore Passphrase = ServerCAKey
Confirm Custom Identity Keystore Passphrase = ServerCAKey
Custom Trust Keystore = \ServerTrust.jks, such as c:\temp\ServerTrust.jks
Custom Trust Keystore Type = jks
Custom Trust Keystore Passphrase = ServerTrustStorePass
Confirm Custom Trust Keystore Passphrase = ServerTrustStorePass
Configuration tab -> SSL subtab
Identify and Trust Locations = Keystores
Private key alias = identity
Private Key Passphrase = ServerCAKey
Confirm Private Key Passphrase = ServerCAKey
Then save.
After this restart your WLS server and you should see similar messages to the following in the WLS logs:
Alternatively is you see the following messages you have made a mistake in your configuration:
3) Modify the web service to use the Wssp1.2-2007-Https.xml WLS policy
This can be done in a number of ways in JDeveloper, the easiest of which for this blog post at least is just to insert the @Policy annotation into the JAX-WS endpoint as follows:
(Note if you're using earlier versions of JDeveloper or Eclipse, this mechanism wont work, you must manually add the policies to the WSDL).
Within JDeveloper to deploy and run from the integrated WLS, it's simply a case of right clicking on the JAX-WS file and selecting Run.
If you click on the hyperlink provided in the log window, this will open the HTTP Analyzer. From the HTTP Analyzer you can open the WSDL at the top of the window:
5) Test the running web service via JDeveloper's HTTP Analyzer
JDeveloper out of the box includes HTTP Analyzer for testing your web services. It's particularly useful as you don't have to leave the confines of your IDE to test your web services.
In order to run the HTTP Analyzer with SSL'ed web service traffic, you need to make some changes to the configuration of JDeveloper. Selecting the Tools->Preferences menu option, followed by Https and Truststore Settings, you can configure the Client and Server keystores HTTP Analyzer needs to run with SSL.
If you followed my exact instructions on setting up a selfsigned CA into the WLS identity and trust keystores, you need to enter the following options in the Preferences Https and Trusting Settings page:
Client Trusted Certificate Keystore: c:\temp\ServerTrust.jks
Client Trusted Keystore Password: ServerTrustStorePass
Server Keystore: c:\temp\ServerIdentity.jks
Server Keystore Password: ServerCAKey
Server Private Key Password: ServerCAKey
When you run your web service you can access the HTTP Analyzer by clicking on the URL of your served web service in the JDev IDE log window, among other methods.
This presents the following HTTP Analyzer screens:
In the top of the screen you'll see the HTTP Analyzer has formed a dummy request for you to send out based on the web service's WSDL. In my example picture I've filled out the part field and pressed Send Request, of which you can see the reply from the web service on the right hand side.
At the bottom of the screen you can the individual request/responses that were generated in order to service the request.
6) Test the running web service via SoapUI
SoapUI is a popular web service testing tool. I wanted to show how to configure it here to show similar results to the HTTP Analyzer. The following steps were built with SoapUI v3.0.
a) Create a new Project via File -> New soapUI Project
b) In the New SoapUI Project dialog, enter a custom project name, then your WSDL, leave the rest of the fields as default.
c) In the Project list expand your new project to the last Request 1 node, and double click it.
d) This will open the Request 1 window, showing on the left handside the outgoing request payload, where you can modify the inputElement XML element with your name.
e) Pressing the green arrow executes the request against the webservice, you'll now hopefully see the SOAP response on the right handside of the window.
f) Note at the bottom right of the right handside of the window you have the text SSL Info. Clicking on this shows another sub-window with the SSL certificate information that was swapped with the WLS server to undertake the SSL communications.
7) Test the running web service via a JAX-WS client
Assuming under JDeveloper you know how to create a Java Proxy for the deployed web service, you'll end up with the following code:
8) Inspect the web service packets on the wire to verify the traffic is indeed encrypted
What neither JDeveloper's HTTP Analyzer nor SoapUI can do is actually confirm for you that the traffic on the network was actually encrypted. To check this we can use a wire sniffing tool called WireShark.
Warning: at some sites using wire sniffing tools like WireShark can be a dismissible offence because you can see private data on the network. Be careful to check your organisation policies before doing this.
Note if you're running the JAX-WS web services via the integrated WLS on the same localhost as SoapUI, you're most likely running through the localhost address. For various technical reasons WireShark cannot sniff packets through localhost or the MS loopback adapter in Windows. Instead we must separate our WLS and SoapUI installations, and place them on different hosts. Let's call them Box1 and Box2, with WLS and SoapUI installed respectively
Once you have both up and running, determine the IP address of Box2. Let's say that IP address was: 101.102.103.104
a) Start WireShark. In the filter box top left enter: ip.addr == 101.102.103.104
b) Select the filter Apply button.
c) Select the Capture -> Interfaces
d) Select the Start button for your ethernet card
e) WireShark is now sitting listening for traffic from the other ip.address of Box2.
f) Now in SoapUI execute the request.
g)In WireShark you should see the incoming requests:
As WireShark works at the network level it sees the individual packets, several of which will comprise the request/response between SoapUI and WLS, effectively an incredible amount of detail. You can select each packet and look at the data contained within in the bottom window of the display. This window shows the data in both hex and raw text, so you'll need to carefully look to see the data contained within. Obviously if the traffic is encrypted you wont see much meaning at all which is what we want! To see the unencrypted traffic, remove the policy from your web service, redeploy it and run the same scenario again.
Thanks
I must aim my very strong thanks to Gerard Davison from Oracle UK with assistance with this article, Gerard's help has been invaluable. Any mistakes in this post are of course mine however, of which I'm sure there will be a few in such a long post.
The following post strips back Gerard's example to instead to consider the steps in setting up and testing One-Way SSL for a JAX-WS web service generated via JDeveloper 11gR1 and installed in WLS 10.3.1, using the WLS policy Wssp1.2-2007-Https.xml.
Assumptions
This article assumes the reader has the following basic knowledge:
* HTTPS/SSL
* Digital certificates and trusted/certificate authorities (CAs)
* Oracle's WebLogic Server, WLS managed servers and the WLS console
One-Way SSL vs Two-Way SSL
For those not familiar with either, Oracle's WLS documentation has a good explanation of the implementation of and differences between One-Way SSL and Two-Way SSL in the Understanding Security for Oracle WebLogic Server manual.
Steps
To implement a One-Way SSL example we'll run through the following steps:
1) Create a basic JAX-WS web service with JDeveloper 11gR1
2) Generate the digital certificates required for the WLS server
3) Modify the web service to use the Wssp1.2-2007-Https.xml WLS policy
4) Deploy the running web service to WLS
5) Test the running web service via JDeveloper's HTTP Analyzer
6) Test the running web service via SoapUI
7) Test the running web service via a JAX-WS client
8) Inspect the web service packets on the wire to verify the traffic is indeed encrypted
1) Create a basic JAX-WS web service with JDeveloper 11gR1
This step is documented in a previous blog post Creating JAX-WS web services via a WSDL in JDev 11g. There are also a number of viewlet demonstrations available from Oracle's OTN which show how to construct the WSDL in a drag'n'drop fashion.
The resulting web service we'll demonstrate here is a very simple one. It is comprised of the following solutions:
OneWaySSLExample.xsd
<?xml version="1.0" encoding="windows-1252" ?>The inputElement and the outputElement will constitute the incoming and outgoing payloads of a simple HelloWorld web service.
targetNamespace="http://www.sagecomputing.com.au" elementFormDefault="qualified">
OneWaySSLExample.wsdl
<?xml version="1.0" encoding="UTF-8" ?>
xmlns:tns="urn:OneWaySSLExample.wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsca="http://www.sagecomputing.com.au">
The overall web service comprises of a single operation accepting the inputElement and outputElement strings as specified in the XSD.
OneWaySSLPortTypeImpl.java
package au.com.sagecomputing.ws;A very basic JAX-WS web service accepting the inputElement String and returning the outputElement String prefixed with "Hello ".
import javax.jws.WebService;
import javax.xml.ws.BindingType;
import javax.xml.ws.soap.SOAPBinding;
@WebService(serviceName = "OneWaySSLService",
targetNamespace = "urn:OneWaySSLExample.wsdl",
portName = "OneWaySSLPortTypePort",
endpointInterface = "au.com.sagecomputing.ws.OneWaySSLPortType",
wsdlLocation = "/WEB-INF/wsdl/OneWaySSLExample.wsdl")
@BindingType(SOAPBinding.SOAP12HTTP_BINDING)
public class OneWaySSLPortTypeImpl {
public String oneWaySSLOperation(String part) {
return "Hello " + part;
}
}
Example request SOAP payload
Chris
Example response SOAP payload
<?xml version = '1.0' encoding = 'UTF-8'?>The overall application/project structure will look as follows in JDeveloper's Application Navigator:
Hello Chris
2) Generate the digital certificates required for the WLS server
In order for a client to undertake a SSL connection with our web service on the WLS server, the WLS server must be configured with a valid digital certificate.
Again note from the Oracle documentation how One-Way SSL works at runtime:
With one-way SSL authentication, the target (the server) is required to present a digital certificate to the initiator (the client) to prove its identity. The client performs two checks to validate the digital certificate:
1. The client verifies that the certificate is trusted (meaning, it was issued by the client's trusted CA), is valid (not expired), and satisfies the other certificate constraints.
2. The client checks that the certificate Subject's common name (CN) field value matches the host name of the server to which the client is trying to connect
If both of the above checks return true, the SSL connection is established.
In this section we consider the digital certificates required for the WLS server.
WLS is an interesting application server in that it keeps two separate Java keystores, 1 for storing the digital certificates for such actions as SSL, and another which is typically used for storing CA digital certificates. The former is referred to as the identity keystore, the later the trust keystore.
The WLS manual Securing Oracle WebLogic Server section 11 Configuring Identity and Trust has a detailed explanation of this setup.
By default WLS comes with demonstration identity and trust keystores containing demonstration digital certificates. As the WLS documentation takes great pains to explain these are for development purposes only and should never be used in a production environment. For the purposes of this blog post if you're testing One-Way SSL in a development environment you can in fact skip this entire step as the demonstration WLS keystores will suffice.
To check that the demonstration keystores are currently installed login to your WLS console, select your server, and under the Configurations -> Keystores tab you'll see the following entries:
Your entries for the file locations of the keystore will be different from my example here dependent on where you installed WLS.
However using the demonstration keystores avoids the whole learning exercise of configuring your own custom digital certificates in WLS which is an important lesson. The following describes those steps in detail, as based off Gerard's original post.
To install our own digital certificate we followed these general steps:
a) Open a command prompt and set the WLS environment
b) Generate our own trusted certificate authority digital certificate
c) Store the private key and digital certificate and import into the identity keystore
d) Store the same digital certificate into the trust keystore.
e) Configure the new keystores in WLS's identity and trust keystore
The following describes those steps in detail. In order to do this we've used WLS utilities to do as much of the work as possible.
a) Open a command prompt and set the WLS environment
Under Windows open a command prompt on the same machine as where WLS is installed, create a temporary directory in your favourite place and cd to that directory, and run your WLS server's setDomainEnv.cmd command. Something like:
"C:\\setDomainEnv.cmd"
Once run ensure you're still in your new directory.
b) Generate our own trusted certificate authority digital certificate
java utils.CertGen -certfile ServerCACert -keyfile ServerCAKey -keyfilepass ServerCAKey -selfsigned -e somebody@xxxx.com.au -ou FOR-DEVELOPMENT-ONLY -o XXXX -l PERTH -s WA -c AU
This generates 4 files: ServerCACert.der, ServerCACert.pem, ServerCAKey.der, ServerCAKey.pem
The utils.CertGen utility is useful for development purposes, but as per the WLS documentation, should not be used for production purposes. Alternatively OpenSSL could be used instead.
Note the use of selfsigned flag. This implies this digital certificate will be used both as the CA in the trust keystore and the served digital certificate in the identity keystore. This is not what we'd do for a production environment using commercial Certificate Authorities, but is sufficient for demonstration purposes in this post.
More information on:
* the WLS CertGen utility can be found here.
* .der vs .pem files can be found here and here.
* WLS provides two utilities der2pem and pem2der can be used to convert between the two file types.
Under Windows you can double click on the ServerCACert.der file to show its contents:
If you have access to the openSSL command line tool you can use it to query the certificate we just created:
openssl x509 -text -inform der -in ServerCACert.der
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0d:a9:d1:4a:0f:0b:b2:61:13:90:89:f5:40:4d:4f:e2
Signature Algorithm: md5WithRSAEncryption
Issuer: C=AU, ST=WA, L=PERTH, O=SAGECOMPUTING, OU=FOR-DEVELOPMENT-ONLY, CN=/emailAddress=somebody@sagecomputing.com.au
Validity
Not Before: Jul 9 07:06:49 2009 GMT
Not After : Jul 10 07:06:49 2029 GMT
Subject: C=AU, ST=WA, L=PERTH, O=SAGECOMPUTING, OU=FOR-DEVELOPMENT-ONLY, CN=/emailAddress=somebody@sagecomputing.com.au
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:df:cb:6c:ed:86:75:4c:5b:66:cd:aa:3d:34:8f:
73:f6:9c:b5:ed:82:9c:c3:15
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:1
Signature Algorithm: md5WithRSAEncryption
b7:fa:1b:8f:c4:ee:af:6b:1d:f0:dc:f4:cf:35:20:f1:df:eb:
0c:fe
-----BEGIN CERTIFICATE-----
MIIC8zCCAlygAwIBAgIQDanRSg8LsmETkIn1QE1P4jANBgkqhkiG9w0BAQQFADCB
i7Pd63d03mWkI85tvsr5Q+40yitOL5JnLsbyHSrM+1aK8kkY7Qz+
-----END CERTIFICATE-----
This identifies information that maybe useful later if we make a mistake, such as the encryption algorithm used (RSA), the size of the keys (1024bit), the serial number of the certificate (a hex number).
c) Store the private key and the digital certificate in the identity keystore
java utils.ImportPrivateKey -certfile ServerCACert.der -keyfile ServerCAKey.der -keyfilepass ServerCAKey -keystore ServerIdentity.jks -storepass ServerCAKey -alias identity -keypass ServerCAKey
d) Store the same digital certificate into the trust keystore
Import the certificate generated in step b into a trust keystore.
keytool -import -v -trustcacerts -alias identity -file ServerCACert.der -keystore ServerTrust.jks -storepass ServerTrustStorePass
e) Configure the new keystores in WLS's identity and trust keystore
To configure the keystores in WLS enter the WLS console, select the managed server you're interested in, then make the following changes under the following tabs:
Configuration tab -> General subtab
SSL Listed Port Enabled = checkbox
SSL Listen Port = 7102 (and different from the Listen Port)
Configuration tab -> Keystores subtab
Keystores = Custom Identity and Custom Trust
Custom Identity Keystore = \ServerIdentity.jks, such as c:\temp\ServerIdentity.jks
Custom Identity Keystore Type = jks
Custom Identity Keystore Passphrase = ServerCAKey
Confirm Custom Identity Keystore Passphrase = ServerCAKey
Custom Trust Keystore = \ServerTrust.jks, such as c:\temp\ServerTrust.jks
Custom Trust Keystore Type = jks
Custom Trust Keystore Passphrase = ServerTrustStorePass
Confirm Custom Trust Keystore Passphrase = ServerTrustStorePass
Configuration tab -> SSL subtab
Identify and Trust Locations = Keystores
Private key alias = identity
Private Key Passphrase = ServerCAKey
Confirm Private Key Passphrase = ServerCAKey
Then save.
After this restart your WLS server and you should see similar messages to the following in the WLS logs:
Alternatively is you see the following messages you have made a mistake in your configuration:
10/07/2009 4:08:30 PM WST>
<10/07/2009 4:08:30 PM WST>
<10/07/2009 4:08:30 PM WST>
3) Modify the web service to use the Wssp1.2-2007-Https.xml WLS policy
This can be done in a number of ways in JDeveloper, the easiest of which for this blog post at least is just to insert the @Policy annotation into the JAX-WS endpoint as follows:
(Note if you're using earlier versions of JDeveloper or Eclipse, this mechanism wont work, you must manually add the policies to the WSDL).
package au.com.sagecomputing.ws;4) Deploy the running web service to WLS
import javax.jws.WebService;
import javax.xml.ws.BindingType;
import javax.xml.ws.soap.SOAPBinding;
import weblogic.jws.Policy;
@WebService(serviceName = "OneWaySSLService",
targetNamespace = "urn:OneWaySSLExample.wsdl",
portName = "OneWaySSLPortTypePort",
endpointInterface = "au.com.sagecomputing.ws.OneWaySSLPortType",
wsdlLocation = "/WEB-INF/wsdl/OneWaySSLExample.wsdl")
@BindingType(SOAPBinding.SOAP12HTTP_BINDING)
@Policy(uri = "policy:Wssp1.2-2007-Https.xml")
public class OneWaySSLPortTypeImpl {
public String oneWaySSLOperation(String part) {
return "Hello " + part;
}
}
Within JDeveloper to deploy and run from the integrated WLS, it's simply a case of right clicking on the JAX-WS file and selecting Run.
If you click on the hyperlink provided in the log window, this will open the HTTP Analyzer. From the HTTP Analyzer you can open the WSDL at the top of the window:
<?xml version='1.0' encoding='UTF-8'?>Note on deployment to WLS you can see that the Wssp1.2-2007-Https.xml policy has been added to the binding to enforce One-Way SSL, and in addition the service address now runs from HTTPS, not HTTP, on the now enabled SSL port.
5) Test the running web service via JDeveloper's HTTP Analyzer
JDeveloper out of the box includes HTTP Analyzer for testing your web services. It's particularly useful as you don't have to leave the confines of your IDE to test your web services.
In order to run the HTTP Analyzer with SSL'ed web service traffic, you need to make some changes to the configuration of JDeveloper. Selecting the Tools->Preferences menu option, followed by Https and Truststore Settings, you can configure the Client and Server keystores HTTP Analyzer needs to run with SSL.
If you followed my exact instructions on setting up a selfsigned CA into the WLS identity and trust keystores, you need to enter the following options in the Preferences Https and Trusting Settings page:
Client Trusted Certificate Keystore: c:\temp\ServerTrust.jks
Client Trusted Keystore Password: ServerTrustStorePass
Server Keystore: c:\temp\ServerIdentity.jks
Server Keystore Password: ServerCAKey
Server Private Key Password: ServerCAKey
When you run your web service you can access the HTTP Analyzer by clicking on the URL of your served web service in the JDev IDE log window, among other methods.
This presents the following HTTP Analyzer screens:
In the top of the screen you'll see the HTTP Analyzer has formed a dummy request for you to send out based on the web service's WSDL. In my example picture I've filled out the part field and pressed Send Request, of which you can see the reply from the web service on the right hand side.
At the bottom of the screen you can the individual request/responses that were generated in order to service the request.
6) Test the running web service via SoapUI
SoapUI is a popular web service testing tool. I wanted to show how to configure it here to show similar results to the HTTP Analyzer. The following steps were built with SoapUI v3.0.
a) Create a new Project via File -> New soapUI Project
b) In the New SoapUI Project dialog, enter a custom project name, then your WSDL, leave the rest of the fields as default.
c) In the Project list expand your new project to the last Request 1 node, and double click it.
d) This will open the Request 1 window, showing on the left handside the outgoing request payload, where you can modify the inputElement XML element with your name.
e) Pressing the green arrow executes the request against the webservice, you'll now hopefully see the SOAP response on the right handside of the window.
f) Note at the bottom right of the right handside of the window you have the text SSL Info. Clicking on this shows another sub-window with the SSL certificate information that was swapped with the WLS server to undertake the SSL communications.
7) Test the running web service via a JAX-WS client
Assuming under JDeveloper you know how to create a Java Proxy for the deployed web service, you'll end up with the following code:
import clientexamples.SSLUtilities;Note SSLUtilities is a handy class written by Srgjan Srepfler that includes a number of methods for handling and modifying the default SSL behaviour. In our case in writing a simple test client we're not overly concerned about trusting the server's CA, so we can use SSUtilities.trustAllHttpsCertificates to stop the required checking.
import javax.xml.ws.WebServiceRef;
public class OneWaySSLPortTypePortClient
{
@WebServiceRef
private static OneWaySSLService oneWaySSLService;
public static void main(String [] args)
{
oneWaySSLService = new OneWaySSLService();
OneWaySSLPortType oneWaySSLPortType = oneWaySSLService.getOneWaySSLPortTypePort();
SSLUtilities.trustAllHttpsCertificates();
System.out.println(oneWaySSLPortType.oneWaySSLOperation("Chris"));
}
}
8) Inspect the web service packets on the wire to verify the traffic is indeed encrypted
What neither JDeveloper's HTTP Analyzer nor SoapUI can do is actually confirm for you that the traffic on the network was actually encrypted. To check this we can use a wire sniffing tool called WireShark.
Warning: at some sites using wire sniffing tools like WireShark can be a dismissible offence because you can see private data on the network. Be careful to check your organisation policies before doing this.
Note if you're running the JAX-WS web services via the integrated WLS on the same localhost as SoapUI, you're most likely running through the localhost address. For various technical reasons WireShark cannot sniff packets through localhost or the MS loopback adapter in Windows. Instead we must separate our WLS and SoapUI installations, and place them on different hosts. Let's call them Box1 and Box2, with WLS and SoapUI installed respectively
Once you have both up and running, determine the IP address of Box2. Let's say that IP address was: 101.102.103.104
a) Start WireShark. In the filter box top left enter: ip.addr == 101.102.103.104
b) Select the filter Apply button.
c) Select the Capture -> Interfaces
d) Select the Start button for your ethernet card
e) WireShark is now sitting listening for traffic from the other ip.address of Box2.
f) Now in SoapUI execute the request.
g)In WireShark you should see the incoming requests:
As WireShark works at the network level it sees the individual packets, several of which will comprise the request/response between SoapUI and WLS, effectively an incredible amount of detail. You can select each packet and look at the data contained within in the bottom window of the display. This window shows the data in both hex and raw text, so you'll need to carefully look to see the data contained within. Obviously if the traffic is encrypted you wont see much meaning at all which is what we want! To see the unencrypted traffic, remove the policy from your web service, redeploy it and run the same scenario again.
Thanks
I must aim my very strong thanks to Gerard Davison from Oracle UK with assistance with this article, Gerard's help has been invaluable. Any mistakes in this post are of course mine however, of which I'm sure there will be a few in such a long post.