Access Manager 7.1 Beta in Java EE Tools/NetBeans 5.5 Enterprise Pack

6 minute read

If you’ve been following Eric Leach’s blog, you’ll know that, just before JavaOne, we released a beta version of Sun Java System Access Manager 7.1 via a couple of bundles:

The former download is 132 MB, the latter 89 MB. The main difference between them seems to be that the Java EE 5 Tools Bundle includes NetBeans; NB EP 5.5 assumes you already have it.

Access Manager’s role in this bundle is to secure web services. If you’re thinking “Uh oh - this is that Liberty stuff they keep pushing at me; I’ve barely got my head around basic SAML assertions, let alone ID-WSF.”, well - relax. We did show Access Manager working with Java Studio Enterprise and JSR 196 (Java Authentication Service Provider Interface for Containers) to secure web services via Liberty ID-WSF at last year’s JavaOne (there’s also a technical article on the topic); since then we have implemented WS-I BSP to secure ‘plain vanilla’ web services.

Here are my notes from installing the Java EE 5 Tools Bundle Beta and working through the Securing Web Services tutorial. I’m running Ubuntu 6.06 ‘Dapper Drake’ Beta. Not an officially supported platform, but I like to surf the bleeding edge

  • Let’s get started. I downloaded the Java EE 5 Tools Bundle Beta, chmod +x; ./ and I’m into the installer. I need to tell the installer where I’ve put Java - it doesn’t seem to know. Fair enough - this is not a standard system - I have at least three versions of Java floating around.
  • The installer prompts me for ports, passwords and trundles away for a while. On completion it reports that there were some warnings. I check /tmp/netbeans-5_5-installation-20060523143837.41310.log and it looks like the installer was not able to get to Access Manager (AM) at http://_myhostname_:8080/amserver/configurator.jsp. Ah - that’s probably because it likes your system to have a fully qualified domain name (FQDN), e.g. and I don’t have a domain set. This is documented in the release notes - it doesn’t seem to be a big deal, and I can get to that URL in Firefox, so we’ll just carry on.
  • OK - surf to http://_myhostname_:8080/amserver/configurator.jsp and I get a nice configuration page:

    Those are the 5 parameters you need to set to configure AM. I left everything as default and (as expected from the release notes) got a server error. Putting a dummy domain on the end of the hostname did the trick and I’m at an Access Manager login screen.

    Cool! The simplest ever AM install/config
  • Login with the default amadmin/admin123 (we’ll have to change that - I hate default passwords. We should add ‘amadmin password’ to the 5 configuration parameters) and I’m in the now familiar AM 7.x admin UI:
  • Ok - install and config done. On to the Securing Web Services tutorial. The tutorial notes are a little sketchy - I’ll fill in the gaps here as I go along.
  • Grab the sample source and put it somewhere sensible, as suggested in the tutorial. I get two directories, stockclient and stockservice. Cool.
  • Tutorial step 2 is missing an initial steplet - you need to go to the App Server admin console at http://_myhostname_:4848/ and login as admin with whatever AS password you selected at install. Hmm - I don’t see a ‘Runtime’ tab, but I can see a running App Server (in fact, I already checked that it was running by browsing http://_myhostname_:8080/ and, of course, I wouldn’t have been able to configure AM if it wasn’t running. So, according to step 2c, I can safely skip forward to step 5 in the tutorial. Except that it seems like the next thing I have to do is in step 3.
  • Tutorial step 3 - yes - done this already.
  • Step 4 - ah - you will definitely want to do this - set AM to full message debug logging. On my system, the config file was at /home/pat/SUNWappserver/addons/amserver/ Beware - there is another file for the AM server - on my machine it’s at /home/pat/ If you set message debug logging at the AM server but not in the AS addons, you won’t get any of the diagnostic output described below. I know - I did exactly this first time round and spent several hours trying to figure out what was wrong. Change to message and restart the App Server. Just go to _wherever_you_installed_it_/SUNWappserver/bin and do ./asadmin stop-domain; ./asadmin start-domain.
  • Step 5 - Run NetBeans and disable proxies as directed in the tutorial, since we’ll be interacting with local services.
  • OK - now for some secure web service action… Start NetBeans and… Oh. NetBeans just shows me a blank window. That’s not good. Google Google Google… Ah. I have XGL and Compiz eye candy installed. This forum post gives the answer - run the Xnest nested X server, the icewm window manager and then run NetBeans in the nested X session. Fair enough. Ubuntu recommends Xephyr rather than Xnest, so I grab that, icewm and.. great - we have NetBeans! [UPDATE: See this comment for a handy little script I wrote to run NetBeans in a nested X session.] Back to the tutorial…
  • Open the two projects. Cool - Web Service Provider (WSP) Security Configuration property page. Enable security, select SAML-HolderOfKey, sign reponses. Don’t forget to change the password if you overrode the default AS ‘adminadmin’ password. Ooh - we’ll have to fix that password entry field. This is beta, don’t forget.
  • We can go look in the keystore, just to check that we are supplying the right password here, and that the s1as cert is there:

    ``` pat@patlinux:~/SUNWappserver/domains/domain1/config$ keytool -list -keystore ./keystore.jks -storepass password Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry s1as, May 23, 2006, keyEntry,

*   Now to the client... Web Service Client (WSC) Security Configuration, enable security, SAML-HolderOfKey, verify response. Check that password again. And we're ready to run. Build and deploy stockservice as described in the tutorial. Build and run stockclient and we have a JSP ready for input. I had to copy the URL into the browser in my main X session, since Firefox wasn't happy running a second instance in the nested X session. I also had to change 'localhost' in the URL to my real hostname.
*   Now I just press enter to get a quote for SUNW and... I get a page of canned price data. It works!!! On my machine, `ClientModule` and `ServerModule` are in `/tmp/amserver/`, I can see real, honest to goodness WS-I BSP SOAP messages with SAML assertions in the headers. I've indented for clarity and elided most of the base 64 encoded signature and key info.
*   Here's the raw SOAP message as it leaves the client code (don't forget, the whole point of this is to abstract the security stuff out of the client/server code):


*   And here is the secured SOAP message as it goes onto the wire:

wsc urn:oasis:names:tc:SAML:1.0:cm:holder-of-key CN=patlinux, OU=Sun Java System Application Server, O=Sun Microsystems, L=Santa Clara, ST=California, C=US AIE1oq... AQAB zdCY/1iqOMUJq/RvxsaDPWM4+7c= ApcX/D... MIICmj... Sccy9a3A7Ps27f3pf9adkRWuGvU= aE9vKM... s69f7e258e30da2b9b9f5799d4eb0c548782432bf SUNW


So - in the next thrilling installment, we’ll walk through that secure SOAP message and see what each bit actually does.

UPDATE - here is that next installment.




My handy shell script for running netbeans in a nested X session:

#! /bin/bash
# You could use Xnest instead of Xephyr here
Xephyr :2 -ac -screen 1024x768 &
icewm --display :2 &
export DISPLAY=:2
~/netbeans-5.5beta/bin/netbeans &

Using the tutorial, I thought I would develop a Web Service using netbeans and the j2ee bundle to … I had no problem editing the web service attributes to set the security settings, but when i created a client with a web service reference to this service I could not edit and set the web service setting to enable the WSC to send the corresponding security headers to the WSP. Instead I got “Project not supported” in both netbeans on OS X and Linux. So, I can’t apparently use netbeans enterprise pack to set the client settings, but must edit the sub-web.xml directly? It appears the reason why the tutorial worked is because all the stubs were already there and not generated? Also, if you leverage the “blueprints: Identity_BP1” and start reading into the section about “Configuring WebService Client Security Mechanisms Using the Access Manager Console” you find the tutorial completely off the rails from how the amswer is configured. So, I don’t know what to make of that, because the some 4 individual Access Manager 7.1 PDF docs don’t cover securing web services in the manner these tutorials do. Thoughts?


Seems like you are creating a Java EE 5 webservice using NB, correct? In the case of Java EE 5 based service, after creating the web service client node you have to also “use the client” node in one of your sevlets/jsp etc.. which will generate a @WebServiceRef annotation which signals the tool that it can enable security. The key is to have the annotation on the client which invokes this service. If you used the bundled stock sample from the IDE (or use the zip file that Pat has included) you would be able to invoke the client wizard without this additional step because the samples are j2ee 1.4 based and hence the workflow for client creation is different. HTH,

  • Vidhya

Yes, you’re corrrect. I have created a Java EE 5 webservice using NB, and then followed up creating the web service client in another project using NB tool features, and created a reference to the the service under “Web Service References” folder in NB. So, I have to apply @WebServiceRef annotation on the servlet making use of the Web Service Reference? I gotta read up more on Java EE 5 web service development… As I’ve written namely j2ee 1.4; specifically, axis based services.


You dont need to manually create a @WebServiceRef annotation. If you have a servlet where you want to use this service reference, just drag and drop the client reference node into the servlet where you want to invoke he service.. this would automatically create the annotation for you and then the security dialog will be enabled. - Vidhya


Ahh, it seems Vidhya has been around this block before as I haven’t been alone to experience this issue. Okay as per your directions, I added @WebServiceRef(wsd=”http://localhost:80080/MagicEightBall/MagicEightBallService?wsdl”) soa.example.client.MagicEightBallService service; to my servlet class, then later on in the appropriate servlet method soa.example.client.MagicEightBall port = service.getMagicEightBallPort(); This builds and deploys but won’t run, even if you choose to edit the services attributes to disable message level security under the WSP security configuration and then redeploy. You get security related exceptions as soon as the client tries to connect to the service. It appears that you need to strip out all the security related xml additions to the sun-web.xml file, and remove the amconfig.xml file, then redeploy inorder to get the service and client to work again minus message level security. Now, that I verified my service and client work, I attempt to re-enable message level security on the service… That goes off without a hitch, but I still can’t get nb to allow me to edit the security via the web service attributes panel of the client’s web service reference. It still return “unsupported project.” Is the Q-build of the enterprise bundle available, because I don’t see it at Your forum post mentioned it back in October… -Michael


okay, just saw the drag dropp response… yeah, that works… you have to drag the method from the web service reference… and it drops in a bunch of canned code to access the method… sweet. Yet, “project not supported” still is their under the edit web service attributes… So, i gotta keep dropping and dragging ‘til it pops up cause of the bug?


There is a bug filed and tracked about this random “project not supported” showing up in java EE 5 projects. Looks like you are seeing this. Just few tries would make this message go away.. atleast for the workaround I didnt have to restart. - Vidhya

Leave a Comment

Your email address will not be published. Required fields are marked *