Simplifying COREid Identity System Menus

A common request for COREid customization is removing unused menu options in the User Manager, Group Manager, and Org. Manager applications (like Create User Identity, Deactivated User Identities, Configuration, etc). Some of these customization tasks can be achieved by defining custom user types in obnavigation.xml, avoiding the need for XSL customization.

Unwanted menu options can be removed from a user type or multiple user types can be defined. Choosing one of these defined user types can be done in the following manners (in order of increasing weight):

1. Set the default userType in obnavigation.xml


2. Define an action to pass an attribute or value from the Access System containing the name of the user type as a header variable (named HTTP_OBLIX_USER_TYPE by default)


3. Add a userType=[name] query string parameter to any URL within the User Manager, Group Manager, or Org. Manager

Note: userTypes are different from Styles in COREid, and customizations to each will function independently from the other.

Simple Mode Cert Regeneration (Access)

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 -RRestart the COREid component to get it to bind to TCP/IP port with the new certificate.

See Also: Simple Mode Cert Regeneration (Identity)

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

AD/AM Unsecured Passwords

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.

Access Manager Looping

Ever enabled the NetPoint Identity Domain policy domain but not NetPoint Access Manager? It’s a good way to lock yourself out of the Access Manager with a looping redirection behavior. To fix this problem, identify the LDAP objects in your COREid policy container that represent these policy domains, enable or disable one (obEnabled attribute), and restart the AAA service and web server.

• They will be located in OBAPP=PSC,OU=oblix,[Policy Container]
• They will be an objectClass of oblixSiteDomain
• OBNAME will likely start with OBAutoSSO (if they were created by the access system install)
• Check the obdisplayname

Certificate Expiration Dates #2

A quick fix for an expired simple mode cert is to simply copy the 3 .pem files from the ../config/simple directory of a component that is still working, and restart the service. These certificate files are completely interchangeable within an environment (I think that the only requirement is that they need to be generated using the same passphrase). When copying between Access and Identity components, be sure to change the file name prefix (ois/aaa).

To quickly identify the expiry date of a simple mode certificate on a Windows system, make a copy of the cert file (ois_cert.pem or aaa_cert.pem), rename the extension to .cer, and double-click it.

Also see: NulliBlogs - COREid Nitty-Gritty: Certificate Expiration Dates

COREid Dual Transport Mode Operation

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.

Simple Mode Certificate Duration

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.

Ultimate COREid XSL Customization Development Environment

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!