When simple mode certificates are going to expire, they need to be regenerated so the component(s) that have the old certificates may still communicate with other COREid components. The method for regenerating certificates varies between the COREid Access and Identity Systems. The Access Server, WebGate and AccessGate components all use the configuration tool relevant to their install. These are as follows:

• <coreid_install_dir>\oblix\tools\configureAAAServer
• <coreid_install_dir>\oblix\tools\configureWebGate
• <coreid_install_dir>\oblix\tools\configureAccessGate

Access Server
configureAAAServer reconfig "c:\Program Files\coreid\access"

WebGate
configureWebGate -i "c:\Program Files\coreid\WebComponent\access" -t WebGate -R

AccessGate
configureAccessGate -i "c:\Program Files\coreid\WebComponent\access" -t AccessGate -R

Restart the COREid component to get it to bind to TCP/IP port with the new certificate.


See Also: Simple Mode Cert Regeneration (Identity)

When simple mode certificates are going to expire, they need to be regenerated so the component(s) that have the old certificates may still communicate with other COREid components. The method for regenerating certificates varies between the COREid Access and Identity Systems. The Identity Server and WebPass (and Access Manager too) have a utility called gencert. The gencert utility is located in:

<coreid_install_dir>\oblix\tools\gencert

to use the tool to regenerate certificates, execute gencert as follows:

gencert.exe "c:\Program Files\COREid\identity"
OR
gencert.exe "c:\Program Files\COREid\WebComponent\identity"

Restart the COREid component to get it to bind to TCP/IP port with the new certificate.

See also: Certificate Expiration Dates #2

Have you ever needed to bulk load AD/AM with a bunch of LDIF users for testing or conversion purposes, but been frustrated by its inability to allow password changes over an unsecured port? Well this is can be easily remedied using the dsmgmt tool that is installed with AD/AM. The tool is located in c:\WINDOWS\ADAM. Here is an example of making the change to an AD/AM instance:

C:\WINDOWS\ADAM>dsmgmt
dsmgmt: ds behavior

ds behavior: Connections

server connections: connect to server localhost:389
Binding to localhost:389 ...
Connected to localhost:389 using credentials of locally logged on user.

server connections: quit

ds behavior: Allow passwd op on unsecured connection
Successfully modified DS Behavior to reset password over unsecured network.

Now entries can be added to the directory with clear text passwords. The setting can be just as easily reversed after the changes are made.

NOTE: making this change will not permit the COREid identity system to change passwords in AD/AM over an unsecured port. I am not sure why, but something in the application prevents it even though the AD/AM instance is configured to allow it.

There is a little known, unsupported feature of COREid that allows server components to listen in two transport modes at once: either open/simple or open/cert. I had the good fortune of discovering this feature about 5 years ago. I had to convert a live production system that was installed in open mode to cert mode. We were looking at taking downtime to do the change, but by pure chance I stumbled accross another solution. I had reconfigured an identity server component, to listen in cert mode and it was late a night and I forgot to switch the transport mode in the COREid UI to cert from open. I started the identity server without making the switch and tested the port to see if it was listening in cert mode. When you telnet to the identity server port it responds with the mode in which it is listening.

I was expecting to see the word

CERT

but what I saw instead was

OPEN
CERT

This was a welcome surprise for us. It meant that we could convert the identity and access servers one at a time to listen in both modes without taking the entire service down. Then after giving all of the application owners sufficient time to reconfigure their Webpasses, WebGates and AccessGates we could turn open mode off (by switching the transport in the UI to cert). This worked very effectively.

By default Oracle COREid simple mode certificates are issued for 1 year (365 days) by default. If you would prefer a different expiration time you can change the setting that controls the certificate's duration. There are two files that control the duration, each is used depending on the certificate (re)generation situation. I think it is best to just change both files to cover your bases.

• <coreid_install_dir>/oblix/tools/openssl/openssl.cnf
• <coreid_install_dir>/oblix/tools/openssl/openssl_silent.cnf

The paramater to change is "default days"...

default_days = 365 # Duration to certify for

Change this to the desired number and regenerate your simple mode certificate.

Some people look at the vanilla COREid interface and make a quick decision that they don't like it, or that it's not what they hoped it to be. These people fail to recognize is that the original designers were only trying to deliver a functional starting point for all. The designers knew that they could not build to satisfy everyone's specific business cases.

But behind this vanilla first impression is flexibility and power that goes unrecognized by many customers. To access it, you need a web developer who is willing to tackle the reasonably short learning curve of XSL 1.0. It is a slightly different programming paradigm - but once you're there, it's quite simple.

These days, everyone is talking about Web 2.0 and AJAX. Well, there's nothing stopping you. If you want a GMail like experience backed by COREid Identity services, it is there for the taking.

If you are this web developer working to make your Identity interface do backflips, here is a recommended development set up that will help speed you on your way to success.

The key to XSL development is the ability to iterate rapidy. This is the main reason that you should not do your customization work against a live COREid server. Even if you dial the stylesheet cache down to 1 you still lose time bumping the cached sheet with every change.

What you want to do is craft a representative development environment on your local machine. Here is what you need: Inside a root folder of your choice create three sub folders; client, server, source. From your WebPass installation copy the /identity/oblix/lang folder into the local 'client' folder. From the COREid Identity server installation copy the /identity/oblix/lang folder to the local 'server' folder. Also, under the local 'client' folder, create three more folders nested (step1/step2/step3). Now, capture some Presentation XML from the user stories that you are customizing and drop these files into the local 'source' folder. Take your XML editor of choice (we recommend Oxygen XML) and configure your transformation scenarios to output html into the local 'step3' folder. Finally, run a local webserver and configure it to allow directory browsing at the root of the 'client' folder. Now, after doing a transformation, you can browse to http://localhost/client (or whatever you called it...) and then navigate down to /step1/step2/step3/my.html and view your results.

With this structure intact, you should find that, not only is your iteration speed increased, but that you also have intact references to all images and client side JavaScript which enables development on this front as well.

Happy customizing!