Forms, RADs and Common Access Cards - It Works

After three weeks of twelve hour days, lost weekends, and two trips to our customer's location, we finally have an Oracle Forms application that can be accessed with Department of Defense Common Access Cards (CACs).

CACs are smart cards containing a PKI certificate. The military uses these for ID cards and for gaining access to the .mil domain. Users have to insert their CAC into a reader at a workstation to login to their local network.

We built a login module using two java servlets and a simple html form to read the users common name attribute from the card's distinguished name. The CAC's common name contains a unique identifier that is used to create an entry in Oracle Internet Directory. We use Oracle's sample forms_rad pl/sql package to create a Resource Access Descriptor for the user and store it in OID as well. After the user's OID entry and RAD are created, they are turned over to Forms, which is configured for Single Sign-On. Single Sign-on authenticates the user and Forms then pulls the RAD from OID and connects to their backend database account.

Although it was often frustrating, it was a great learning experience. My next project is to convert the servlets into .jsp pages. Now that we've got the configuration licked (about 75% of the effort was getting the Oracle Application Server 10g (10.1.2) configured correctly) this should be fairly simple.

Several folks posted helpful suggestions to previous entries in this blog and once again I'll say thanks to all for your help. If anyone has any questions about our configuration please post them here and I'll do my best to answer your questions.

SSO, OID, Multiple Realms, and Windows - A Sob Story

Was in the process of setting up a test environment to test my PKI certificate Forms/SSO login module's ability to login users who's DNs didn't match the default realm and discovered I would need to register the second realm with SSO after creating it in OID.

Dug into section 10 of the Oracle Application Server Single Sign-On Administrator's Guide and lo and behold the two scripts provided by Oracle to register a second realm with SSO are C shell scripts, specifically enblhstg.csh and addsub.csh.

C shell scripts don't run on a Windows box. In fact, the guide helpfully tells you this. No .bat files, no perl, just C shell scripts.

I worked until 10:00 p.m. last night (we're on a Monday deadline to deliver this solution) de-coding the scripts. I found two PL/SQL scripts and one procedure that applied to SSO (the rest are for Portal, which we don't use). I did some further de-coding and figured out what parameters these scripts needed. I got one of the scripts to run successfully from SQL*Plus, the second I de-coded further and did a manual insert into orasso.wwsub_model$ of what I assumed to be the correct values. But it didn't work, SSO does not recognize the second realm and now I'm waiting while my OAS 1012 installation wipes itself out. I'll rebuild it and set the default OID realm at the highest level possible (dc=com) and hope that the containers I create under it for the different DN's works - but I'm not too optimistic and I've kissed my weekend goodbye.

I discovered this blog has been linked to an Oracle blog aggregator - if anyone from Oracle is reading this please tell us WHY you would ship a product for a Windows platform but provide scripts that can only be run on UNIX/LINUX platforms?

I mean really - what the hell?