[ Home | Products | Services | Download | Contacting Adiron | Links ]
[ CSIv2 Interoperability Testbed ]
[ ORBAsec SL3 ] [ AdironORB ]

CSIv2 Interoperability Testbed Page

Welcome to the Adiron Common Secure Interoperability Version 1 (CSIv1) and Version 2 (CSIv2) Testbed Webpage! Adiron has made several CSIv1 and CSIv2 enabled objects available on our servers on which to try your CSIv2 security service products. C'mon and join the Fun!

Primary Test: Say Hello to our Johnson!

The way the test works it that you construct a simple client for one of our Johnson objects. A Johnson object has the operation "say_hello", which is found in the IDL file, InterOpTest.idl . It takes a simple string as an argument and returns a simple string, as follows:

    string say_hello(
        in string tell_me_who_you_are
    );
Then you get your client to invoke an IIOP, CSIv1, or CSIv2, enabled request on our Johnson object reference and see what you get!

We have different Johnson object references with different security mechanisms listed below .

The Return Result

If the request is successful, you will get a return string. This string will contain a message containing the value you supplied in the "tell_me_who_you_are" argument, and a formatted version of a SecurityLevel3::Principal value type as per the ORBAsec SL3 product. A successful result may look like the following:
Message from you : "This is Adiron!"
Your full client principal is:
valuetype SimplePrincipal {
  the_type = 0
  the_name = struct PrincipalName {
    the_type = SL3:X509DirectoryPathName
    the_name = {
      "EMail=adiron00001@adiron.com,CN=Homer Simpson (Identity not validated),O=AddTrustTTPNetwork,OU=AddTrust2Mail,OU=http://www.addtrust.com/addtrust2mail,C=US"
      "CN=AddTrust2MailCA,OU=AddTrust TTP Network,O=AddTrust AB,C=SE"
      "EMail=info@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 1 Policy Validation Authority,O=ValiCert, Inc.,L=ValiCert Validation Network"
    }
  }
  environmental_attributes = {
    PrinAttribute("SL3:TransportMechanism","TLS")
    PrinAttribute("SL3:TLSCipherSuite","SSL_RSA_WITH_3DES_EDE_CBC_SHA")
    PrinAttribute("SL3:ChannelIdentifier","TCPIPv4:127.0.0.1:40353-128.230.111.5:40325")
    PrinAttribute("SL3:EstablishmentTime","994191795617")
  }
  with_privileges = {
  }
  authenticated = true
  alternate_names = {
  }
}
This message indicates that the Johnson object authenticated its client as "Email=adiron00001@adiron.com,...." from an X.509 certificate using the TLS ciphersuite SSL_RSA_WITH_3DES_EDE_CBC_SHA", from the IP address of 128.230.111.5:40325.

In the case of using CSIv2 Identity Assertion, your result will show a "valuetype QuotingPrincipal". This object will print out two SimplePrincpals, which is one "quoting" the other.

Error Result

You may very well get a CORBA System Exception of CORBA::NO_PERMISSION back from us for several reasons. This exception may or may not contain a CSIv2 error status message depending on the particular thing that failed. A CORBA::NO_PERMISSION exception will be raised if: The reasons are NOT limited to the above list. There are quite a number of problems that might cause a CORBA::NO_PERMISSION exception to be sent, but they are too abundant to enumerate in full here.

You may get other errors or exceptions. For example, if you are using TLS and you don't have a compatible ciphersuite, the handshake will fail, and the error you get back may be determined differently by the ORB you are using.

USING TLS/SSL

If your are using TLS to contact our TLS enabled Johnsons, you may not be able to connect due to an authentication failure. This failure may occur because your issuer's certificate is not in our trusted certificate store. We do have many certificates in there, but we do not have them all. If you need us to install an issuer's certificate(s) into our trusted certificate store for your test, please send them to us, at support@adiron.com and we will install them.

Our Johnsons are currently using a certificate that was issued by our own test certificate authority. This certificate can be found in PEM format here and PCKS#12 format, here.

Extended Test: Get Our Johnsons to Say Hello to Your Peter!

The IDL file, InterOpTest.idl , shows that the "say_hello" operation actually belongs to the "IDL:/com.adiron/InterOpTest/Peter:1.0" interface, which is inherited by the Johnson interface. A Johnson interface extends a Peter interface with several operations found in the lower table. These operations take your implementation of the Peter interface and perform its "say_hello" operation with the "This is Adiron!" message.



So, basically, we have a bunch of "Johnsons" and if you have a "Peter", you can get our Johnsons to say hello to your Peter!

This procedure only works with the proviso that your Peter is actually capable of receiving a CSIv2 request. This way, you can try your CSIv2 server capabilities as well as just the client capabilities. The following table contains the names of the operations a Johnson has over and above "say_hello".
Johnson Operation What it does to your Peter
say_hello_from_you Invokes on your Peter object with our Johnson's own credentials.
say_hello_from_me Invokes on your Peter object with our Johnson's own credentials. but quoting your client making this request.
say_hello_user_password Invokes on your Peter object using the given username and password.

You can stipulate a number of times for our Johnson to "say_hello" to your Peter. The amount is limited between 0 and 10. This option may test your CSIv2 state retention mechanism, as our Johnson objects are enabled with clients capable of using the CSIv2 state retention mechanism.

The Return Result

Besides the same failures you would get at the CSIv2 level on the immediate invocation to the Johnson object, our Johnson object may incur some difficultly in accessing your Peter object. If there was no difficulty, then the return result from these Johnson operations is a string SUCCEEDED.

Error Result

If our Johnson invocation on your Peter object failed, the return result will contain a string staring with "FAILED" and followed by the indication that it it received one of the following errors:
Exception Meaning
NO_RESOURCES This exceptions may mean our Johnson didn't have the mechanisms to make an invocation on your Peter. Could it be a problem with the IOR? Or us? Our Johnsons support IIOP, CSIv1 SSL, CSIv2 over IIOP and TLS and support Identity Assertion and UserPassword authentication.
NO_PERMISSION Most likely this is a CSIv2 error raised by your Peter object. This is most likely caused by a bad username password that you gave our Johnson in "say_hello_user_password".

Note: Your Peter object may raise any CORBA System Exception, and an indication that it was caught will be returned in the "FAILED" string.

Johnson Interoperable Object References

We have a single Johnson Server running that contains a number Portable ObjectAdapters holding Johnson implementations with differing security characteristics.
Johnson Interface Object References Characteristics
Johnson_IIOP_POA.ior Straight IIOP 1.1
Johnson_TLS_POA.ior CSIv1 SSL enabled.
Johnson_IIOP_CSIv2_POA.ior CSIv2 over IIOP
Supports Identity Assertion
Johnson_TLS_CSIv2_POA.ior CSIv2 over TLS 1.0
Supports Identity Assertion
Johnson_IIOP_CSIv2_UP_POA.ior CSIv2 over IIOP
Supports Identity Assertion
Requires User/Password Authentication with
username = "guest"
password = "password"
Johnson_TLS_CSIv2_UP_POA.ior
CSIv2 over TLS
Supports TLS Authentication (Anonomous Allowed)
Supports CSI Identity Assertion
Requires User/Password Authentication with
username = "guest"
password = "password"
Johnson_TLS_CSIv2_2UP_POA.ior CSIv2 over TLS
Requires NonAnonymous TLS Authentication
Supports CSI Identity Assertion
Requires User/Password Authentication with
username = "guest"
password = "password"
Johnson_ALL_POA.ior This object has all the above capabilities listed in its IOR. (Allows Anonymous TLS Authentication)

System Logs: How am I doing?

We have a some primitive, cryptic logs that can give you some indication of what our Johnsons saw and what they processed.
Log File Meaning
JohnsonConnection.log This file contains logs of the connections that are accepted, initiated, and closed.
JohnsonRequestInterceptor.log This file contains logs of the requests coming in and out of the Johnson Server.
JohnsonResponse.log This file contains logs of the responses of our Johnson Server along with the dialogs it has with your Peter objects.

Source Code

The entire source code which we use code the testbed and test it is available in the "sl3/test" directory of the ORBAsec SL3 distribution. ORBAsec SL3 can be downloaded from our download page .


[ Home | Products | Services | Download | Contacting Adiron | Links ]
[ CSIv2 Interoperability Testbed ]
[ ORBAsec SL3 ] [ AdironORB ]

Copyright 2004 Adiron. All Rights Reserved.
"ORBAsec", "AdironORB", and "SL3" are trademarks of Adiron, LLC.
"Java" is a trademark of Sun Microsystems, Inc. "CORBA" is a trademark of the Object Management Group.
Other names, products and services may be the trademarks or registered trademarks of their respective holders.