First roundtrip interoperability tested for XACML Interoperability

I am a voting member on the Oasis XACML Technical Committee representing JBoss/Red Hat. I am also leading Red Hat's participation at the XACML Interoperability event scheduled at the Burton Catalyst Conference at the end of June in San Francisco.

The last few days, the various vendors participating at the interop event have been discussing scenarios to test such that we maintain interest among the attendees as well as not make them so complex that the first ever interoperability event for XACML fails.

Given this, Jericho systems put their endpoint out for others to test. So the honor of being the first vendor ever to publicly place an endpoint for interoperability goes to Jericho systems.

I was able to test the public endpoint. So this makes me a participator in the first ever round trip interoperability exercise for XACML.

The SAML based XACML response received from Jericho endpoint has been framed for eternity here (an idea by Rich Levinson from Oracle Corp).
First SOAP Response

The honor of framing was mine and there goes my 2 minutes of fame. The rest of the fame will come when I put our endpoints out and other vendors are able to access.

Sun OpenDS CheatSheet

Neil Wilson's cheat sheet to integrate OpenDS as a testing ldap engine in your java apps.

==========
- Make sure that all of the OpenDS JAR files are in your application's
classpath.

- When you're ready to start the server, you can do so as follows:

String configClass = "org.opends.server.extensions.ConfigFileHandler";
String configFile = "config/config.ldif";

DirectoryServer directoryServer = DirectoryServer.getInstance();
directoryServer.bootstrapServer();
directoryServer.initializeConfiguration(configClass, configFile);
directoryServer.startServer();


This will start the server inside the same JVM, and you should be able
to communicate with it using LDAP or using the internal operations API
that we have defined for plugins (via the classes in the
org.opends.server.protocols.internal package).
===============================

New directions in JBoss Security

Well, JBoss Security is not just security specified by the Java EE specifications. With my active participation as the Red Hat representative on JSR-196 at the JCP and Oasis Technical Committees on SAML, XACML, PKI, EKMI and WS-Federation, I am always exploring new things that will make the users of JBoss security feel more secure and have confidence in adopting JBoss as the platform for secure computing.

Given this, I am always happy to interact with my users. You can always send me an email at anil (AT) saldhana (AT) redhat (dot) com. I may not answer immediately but will certainly get back to you, provided you are talking about some meaningful stuff. New features, new directions, new requirements will all be met with glee while RTFM type questions will be ignored.

I also represent on the Security Context Working Group at the W3C.