Dot Net Parsing Oracle Access Manager XML

This is slightly off topic, and extends well beyond just Oracle Access Manager but was a little less than obvious to me the first time I had to do this in .NET (well, also the second time). If the XML you are trying to process with SelectNodes or SelectSingleNode contains a namespace then you need to associate that namespace with a namespace manager and include it in the SelectNodes or SelectSingleNode statement (see example below).

XmlDocument xml = new XmlDocument();
xml.LoadXml(someXmlString);
XmlNamespaceManager ns = new XmlNamespaceManager(xml.NameTable);
ns.AddNamespace("default", "http://www.oblix.com/");
attrNodes=xml.SelectNodes("/default:ObEventParams/default:ObParamList[@name='WfAttribute']/default:ObParam", ns);

IDXML - There is no profile configured for this kind of user

IDXML can be cool. It can also cause one to question one's future in front of a keyboard.

Take, for example, the error message: "There is no profile configured for this kind of user". This is usually a very helpful message that tips you off that you have a typo in the DN value of the UID parameter.

But if you are getting this message and you are sure that your request looks perfect there can be another simple explanation for the error: your HTTP client might be sending the request to the wrong application.

That's right - if you send a perfect Modify User request to /identity/oblix/apps/objservcenter/bin/objservcenter.cgi instead of /identity/oblix/apps/userservcenter/bin/userservcenter.cgi, you will find that 'There is no profile configured for this kind of user'...

Don't let this happen to you. Life is short.

Creating Custom Style Shared Folder

When creating a custom style for Oracle Access Manager (formerly COREid) the product creates a localized directory for you in the default language, but all of the files in the localized copy point back to the main style sheets in the shared directory. In order to keep the vanilla sheets for style0 (Classic Style) intact it is advisable to create a duplicate shared directory (i.e. newstyle_shared).

In order to let this all hang together, however, one must update all of the references in the new styles localized directory (created by the product as part of the new style function) so that they point to the new shared directory (created by you).

As there are many files to update it is adviseable to use a batch search and replace tool for this task.

On a unix system with perl installed this is a very easy proposition. The following command will suffice...
perl -p -i.bak -e "s|\/shared|/newstyle0_shared|" *.xsl

However, on windows it is a little trickier at the windows shell does not like the *.xsl reference. Therefore, a small change is required to make it work in the windows shell...
for %I in (*.xsl) do perl -p -i.bak -e "s|\/shared|/newstyle0_shared|" %I

WebGate Cannot Initialize

A web server with a WebGate installed on it suddenly does not serve pages and generates 500 errors. There have been no changes to the server or the web server configuration. Upon further investigation the Oracle Access Manager (formerly COREid) oblog.log of the WebGate generates a line in the WebGate initialization indicating that it is failing.

ACCESS_GATE FATAL 0x00001520 \Oblix\coreid702\palantir\webgate\src\iisentry_web_gate.cpp:249 "Exception thrown during WebGate initialization" Error^2--- STATUS ------ ERROR ---\Oblix\coreid702\palantir\webgate\src\web_gate.cpp:371: Error: Exception rethrown from ObWebGate::Init( <null> = <null>, <null> = <null> )%0a\Oblix\coreid702\palantir\aaa_client\src\aaa_service_client.cpp:363: Error: ObAAAServiceClient::Initialize()%0a\Oblix\coreid702\palantir\netlib\src\obcreatewrapperfactory.cpp:65: Error: create_tls_wrapper_factory()%0a\Oblix\coreid702\palantir\netlib\src\obtlswrapperfactory.cpp:235: Error: %0a

This indicates that WebGate cannot create a TLS connection to the Access Server so it cannot initialize so it leaves the web server in an unusable state. The likely cause of this is that the certificates on the WebGate have expired.

The certificate expiration dates can be checked by reading this.

The certificates can be regenerated by reading this.

Policy Domain/Policy Not Enforced

Successful migrations of Oracle Access Manager (formerly COREid) configuration data rely heavily on consistent directory naming of entries between envionments. It is not enough for configuration data objects to share the same user friendly names, they must have the same RDN (Relative Distinguished Name) values in the directory server. This forms the basis of clean migrations. As well, objects must share the same properties. If this setup is performed in advance of using the COREid Migration Service or alternatively, corrected in a pre-existing environment using the COREid Migration Service migrations will run smoothly. The situation described below illustrates how having inconsistent environments can cause problems.

After copying a policy domain or policy to a new environment the resources protected by the policy domain and/or policy are not actually protected there. Checking the resources in the Oracle Access Manager Access Tester reveals that the resources are indeed not protected.

This error highlights a mismatch in host identifier data between the source and target environments. It may look the same (i.e. have the same user friendly description in the UI), however, the distinguished name (DN) that names the object in the directory is probably different.

The short term solution is to add the host identifier for that environment in all of the locations in the policy domain(s) and/or policy(ies) where resources are specified. This will get the policy domain(s) and or policy(ies) working again in the target environment. However, there is still a longer term problem that will affect future migrations of policy domain data.

This long term solution is to use the COREid Migration Service to migrate host identifiers and policy domains from a stable environment (production) to all of the other evironments (i.e. quality, test and dev) and systematically update the host identifier entries with host names specific to the environment. This will make the other environments consistent a prevent this problem from occurring in the future.

Anonymous Authentication Resources SLOW

Problem Oracle Access Manager (formerly COREid) is extremely slow or does not serve content from servers protected by the Anonymous Authentication Scheme (formerly Netpoint None). This can include FAQ pages, login pages, images, style sheets, etc.

Background The Anonymous Authentication scheme is used in cases where the WebGate has its DenyOnNotProtected property set to TRUE. The anonymous authentication scheme maps the OblixAnonymous user int eh credential_mapping plugin. By default this is mapped to the uid attribute. The uid attribute is indexed by default in some directory servers but not in AD/AM. In AD/AM the attribute is added as part of the iNetOrgPerson schema extension and is not indexed.

Solution If you are having a problem similar to this one, check to see if the Anonymous Authentication scheme is using the uid attribute in teh credential_mapping plugin. If it is then check to see if the attribtue is indexed in the directory server (if using AD/AM it will not be indexed by default). If it is not indexed then there are a couple of options:

1. index the attribute in the directory (may be harder on some directory platforms than others; very easy on AD/AM)


2. change the attribute in the Anonymous Authentication Scheme's credential mapping step to an attribute that IS already indexed

Potential Cause How did this problem occur? It seemed to just appear over night. The likely cause of this problem is an increase in the amount of data in the user directory server. More data will cause a search on an unindexed attribute to yield incorrect incomplete results more frequently than if there is less data in the directory. This is because the look thur limit the directory imposes on the searhcing user may be exhausted before the entry (or entries) is located.

Can't See Workflow

Successful migrations of Oracle Access Manager (formerly COREid) configuration data rely heavily on consistent directory naming of entries between envionments. It is not enough for configuration data objects to share the same user friendly names, they must have the same RDN (Relative Distinguished Name) values in the directory server. This forms the basis of clean migrations. As well, objects must share the same properties. If this setup is performed in advance of using the COREid Migration Service or alternatively, corrected in a pre-existing environment using the COREid Migration Service migrations will run smoothly. The situation described below illustrates how having inconsistent environments can cause problems.

Have you ever copied a workflow definition from one environment to another and had the workflow not appear in the Oracle Access Manager (formerly COREid) Workflow applet? You double check the target directory server and indeed all of the entries are there so you wonder what could possibly be happening.

If this sounds familiar, then this is likely highlighting a difference between your two environments that you might not know existed. The problem is probably related to when your environments were first built manually independent of one another.
The cause is that there are different objectclasses associated with the tab_id that the workflow is meant to manage.

For instance say in the development environment the Employees tab (default user tab in Oracle Access Manager) has associated with it structural objectclasses of user and oblixOrgPerson. But in the quality assurance environment where you migrated the work flow to it has objectclasses of user, obligOrgPerson and auxCompanyPerson.

This provides an obvious barrier to performing clean migrations between environments. The way to correct this problem is to make the objectclasses look the same. The best way to do this is to get one environment in a pure state (i.e. contains all of your active development) and then migrate it to the other environments. This way all of the environments will be the same and ready to migrate information from one environment to another.

COREid Migration Service

Although we are continuing our invitation only pre-beta phase, all are welcome to peruse the information now publicly available.

https://extranet.nulli.com/migration/

COREid Migration Service Preview

For the folks that have been wanting a closer look at the migration service here is a quick run down with screen shots.

This should give you a pretty good idea what this is looks like.

The Nulli Professional Services team is using this in the the field today and our pre-beta invitees are taking their first steps on their own.





Thanks for your interest so far.

COREid Migration Service Enters Pre-Beta Phase

Nulli Secundus is pleased to announce that our COREid Migration Service has entered a pre-beta (invitation only) phase. We are currently inviting a small group of Nulli customers to begin to use the tool.

The COREid Migration Service is a Nulli hosted web application to which users may upload COREid configuration data in LDIF format. The service processes the data from the source and target environments and returns a single LDIF file suitable for import into the target system. The goal of the Migration Service is to support COREid administrators in duplicating COREid Identity and Access application behavior across separate COREid installations.

The COREid Migration Service will be available at no cost to registered users.

If you would like to be notified upon general release of the service or if you would like to be considered for the pre-beta invitee pool, please send an email stating your interest to mark at nulli dot com.

Create Clean Schema File from AD/AM

Have you ever wanted to get a nice clean schema file containing all of your custom attirbutes and object class entries but exluding the special microsofty attributes from and AD/AM (or AD) instance so that you can archive it off into a source control system or just simply migrate it to another environment? You dread the task becuase you never took the time to automate it so you always edit the file by hand. Well here is a simple regex that you can use to clean up the file after you extract it. The regex as written works in editplus (by far the best editor I have ever used, come on buy it, you know you want to), but can can be easily tweaked to work in other editors, scripts, etc.

Anyway, there are three steps...

1. Extract your data... here is the ldifde way
   

   ldifde -f {filename} -s {server} -t {port}
   -d "CN=schema,CN=configuration,CN={adam_guid}"
   -r {custom object searhc filter}

2. Prune the unwanted attributes
   In the following section it should all be read as a single regex (ignore line breaks). It should be used in a substitution statement where nothing is substituted for the match.
   

   ^(distinguishedname|instancetype|whencreated|whenchanged|
   usncreated|usnchanged|name|objectguid|schemaidguid|objectcategory|msds-intid)
   ::? [^\n]*\n( [^\n]+\n)*

3. Replace the AD/AM GUID to make it really easy to import into a target environment change the GUID in the file to something easy to type that is not repeated elsewhere in the file. 
   
   
   
   
   
   

WebGate and the IE / CSS Flicker Bug

Gettng quite specific here - but if you have this problem, you'll appreciate the info...
There is an annoying behavior that can occur in Internet Explorer. It is referred to as the 'IE CSS Flicker Bug'. This bug manifests as repeated requests being issued for the exact same resource (like a gif image). The result is a very slow or, sometimes, unusably slow user interface as the browser bogs down under (sometimes hundreds) of identical requests. For whatever reason, the IE fails to inspect its own cache for image resources that are defined in a CSS declaration and always issues a new request for each instance of the same resource.
Of course, there is a resolution to the issue. This involves tuning some specific settings on the webserver that serves image files.

IIS Webserver Configuration to Correct IE Flicker

The trick is to specifically set some content expiration and cache control headers that trigger IE to look into its own cache before issuing a new request.
On the directory that contains the resources in question configure: (the following is IIS specific but you can extend the same concept to Apache, etc.)

• Enable Content Expiration
• Expire after 30 days
• Cache-Control: max-age=2592000;

! note: there is a typo in the screen shot where the dash character is missing from CacheControl. Should read Cache-Control.

Where the WebGate Fits In

That's all the info you can find about this issue on the web. But if the UI in question is protected by a WebGate, you might apply the above mentioned measures only to find no improvement in the browser behavior. By default, the COREid WebGate is configured to apply two HTTP headers to each response it handles. Out of the box, the value for both CachePragmaHeader and CacheControlHeader is no-cache. Because the WebGate is always the last component to apply headers, it effectively overrides the headers supplied by the web server.
In the WebGateStatic.lst file, change both the CachePragmaHeader and CacheControlHeader to 'public'. (Yes, this may have other consequences so test carefully.)

That should be all that is needed to end any issues with the IE CSS Flicker bug if it, one day, plagues you.

COREid services start before LDAP

In COREid deployments where the Access and/or Identity services are installed on the same box as the LDAP server, the COREid service(s) sometimes start faster than LDAP. This behavior will cause errors in the oblogs (ie Directory is unreachable, down, or incorrect connection parameters were specified) after a reboot, and will cause the service(s) to stop (when the LDAP in question contains the COREid configuration container).

To avoid this problem on Windows platform installations, dependencies between the services can be created:

1. Locate Registry Entry for LDAP Service and note name: (ie HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ADAM_*)
2. Locate Registry Entry for COREid Service(s): (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ObAAAServer-*, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ObOISServer-*)
3. In each, add a Multi-String Value called DependOnService with a value that is the name of the LDAP service (ie ADAM_*)
4. Reboot

After rebooting, the COREid service(s) will wait until the LDAP service has sucessfully started before starting.
Additional Notes:

• This type of configuration is only useful when the COREid service(s) are configured to ONLY connect to one LDAP instance (no failover or redundancy) that is located on the same server (ie development/test environments)
• Multiple LDAP service names can be added to these registry keys (if using seperate LDAP directories for user, policy, or config containers)
• This dependency relationship will also cause COREid service(s) to restart/stop when restarting/stoping LDAP service

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!

Certificate Expiration Dates

have you ever had a certificate expire and COREid components stop functioning on you. Once you figured out that it was a certificate you were like, "oh-oh, there might be a few more expiring in the next few minutes, hours, days, etc." This is one of those things that us mere mortals re-learn how to do once a year and then promptly re-forget immediately afterwards.

The openssl tool installed alongside each COREid component can be used to determine the valid dates for a certificate. The following example examines a self signed COREid certificate ("simple mode") . The same example holds true for all COREid components: Identity Server, Access Server, WebPass, WebGate and Access Manager (frequently installed alongside WebGate).

C:\>cd \Program Files\COREid\WebComponent\access\oblix\tools\openssl
C:\>openssl x509 -in ..\..\config\simple\aaa_cert.pem -noout -dates
notBefore=Mar 28 22:23:15 2005 GMT
notAfter=Mar 28 22:23:15 2006 GMT

Access Server SDK on IIS5 / IIS6 (Part 2)

so we got the COREid AccessServerSDK working from ASP pages (part 1 here), but then we roled out to ASPX pages and low and behold we had the same problem. checked the permissions for IWAM_ and they were ok. then it dawned on Mark to check the permissions for the ASPNET user. We set those the same as for the IWAM_ user and sure enough success!

Access Server SDK on IIS5 / IIS6

One of the simplest things you should ever need to do with COREid in to install the Access Server SDK and access its functionality via ASP or ASP.NET on IIS6.

The key word here is should.

Sometimes you do everything right:

• Install the binary (theoretically no location requirement)
• Create the AccessGate profile
• Associate the profile with an Access Server
• Run configureaccessgate.exe
• Set OBACCESS_INSTALL_DIR
• Add %OBACCESS_INSTALL_DIR%\oblix\lib to the PATH
• Register the DLLs

And then something like:

validateSDKinstall.asp

< % @LANGUAGE="VBSCRIPT" % >
< % OPTION EXPLICIT % >
< %
dim accessgate
Set accessgate = CreateObject("Netpoint.ObAccessAPI")
accessgate.Initialize
Response.Write "If you see this, all is well"
% >

should run without error. Should.

Sometimes it doesn't.

We've seen a couple of instances lately (7.0.2 / IIS6) where things just don't pan out. The error code that shows up in the IIS logs is 80010105 and in the browser is Error '80010105'. Some googling reveals this is generally, maybe, a network security/permission problem. However, that is not the case with the AccessServerSDK. Upon turning up the log levels on the AccessGate we discovered file system permission errors. Not by what showed up in the oblog.log, but by what did not. Specifically, the log write could not initialize (FileLogWriter::initializeWriter() is the source of the error in the event viewer). This was the first clue that the problem was related to file permissions. The local IWAM account did not have the necessary permissions to write to oblog.log. Once this was corrected, oblog.log started logging and revealed that there still was not sufficient permission to create the necessary lock files.

So, if you run into something like this - check your FS security on AccessServerSDK/oblix.

Horizontal Migration of COREid Configuration Data

The professional services consultants at Nulli Secundus live and breathe COREid on a day to day basis. And we do so in a wide variety of customer environments. It goes without saying that we are always learning and improving the patterns we employ to achieve success with Oracle COREid Identity and Access.

One common customer question that comes up with every engagement is, "How do we move this stuff?". Meaning- "We're following best practices by staging our environments but we don't see a good way to move development to quality assurance, and quality assurance to load testing and on to production...".

Pam Dingle started working on this problem at Nulli Secundus some time ago. Janelle Jowsey took me under her wing as she turned Pam's invention into a software product that worked magic on COREid configuration across staged tiers. The result of all this thought and effort is the fact that there is literally nothing we do not know about the inner workings of the COREid configuration data.

At this point in our history with COREid we know exactly how it should be deployed and staged, and we have the knowledge and tools to efficiently migrate COREid configuration data across enviroments. We can demonstrate perfection in the movement of any Identity or Access application configuration data and we can do so measured in a scale of minutes.

We're in the process of formalizing the ways that we can share our knowledge and tools most effectively with the COREid customer population. Watch for more information on our web site coming in the second quarter of 2006.

If you're really keen to put an effective system around this challenge in your environment and you want a hand in shaping some of the stuff we're working on, please get in touch with us. We'd be pleased to talk with you and would welcome your input.

New Response Phrase - No Old Response

Have you ever wanted to let users update their challenge response phrase in COREid without requiring them to enter their old response? There are two requirements to make it happen: (1) workflow for updating challenge response for the user class in question and (2) no read/modify AAC on the challenge response attribute for that user class.

Substitution Syntax in Search Base and Attribute Access Control

Have you ever got confused when using substitution syntax in COREid search base and attribute access control settings? They natural thing to get backwards since they are backwards (from each other that is). Question is, which one is which? Does the logged in user go in the left hand side ot the right hand side? Does the substitution go in the left or right? Well, that one at least is easy; the substitution attribute $attributename$ always goes on the left, errr, I mean right. I just can never remember which one it belongs to: logged in user or objects being searched/viewed/edited/notified?

Well, this is how it works:

Search Base gets set up so that the logged in user's information goes on the right side of the equation, the substitution side. For instance, the substitution might look like this...

org=$myorg$

This basiccally says that the search is restricted to all of the objects that have an org that is the same as $myorg$, where $myorg$ is an attribute in my profile and org is an attribute on another object.

Well, is that is how search base works then AAC must be the opposite.

Attribute Access Control gets set up so that the logged in user's information goes on the left side of the equation, the non-substituion side. For instance, the substitution might look like this for a rule that allows a manager permission to a particular attribute and right...

distinguishedname=$manager$

This essentially says give me (distinguishedname - MS centric example) permission to do this (right) for this attribute where I am the manager. Although I do not know why you would do this explicit thing since COREid already supplies a role for DN based attributes (like manager) that accomplishes the same thing.

ADAM Changing Page (Search) Limit

Ever wanted to reduce or increase the AD/AM search limit (page size)? For instance you are doing a COREid upgrade and part way through the directory update portion it fails with a directory error. It was not able to extract all of the COREid meta data because the search limit was exceeded. The solution is to ramp up the page size in AD/AM even if it is just for the upgrade.

C:\WINDOWS\ADAM>dsmgmt
dsmgmt: LDAP Policies

ldap policy: connections

server connections: server connections: set creds [domain] [user] *

Please enter password for [domain]\[user]: ********
server connections: connect to server localhost:389
Binding to localhost:389 as [domain]\[user]...
Connected to localhost:389 as [domain]\[user].
server connections: quit
ldap policy: show values

Policy Current(New)

MaxPoolThreads 4
MaxDatagramRecv 4096
MaxReceiveBuffer 10485760
InitRecvTimeout 120
MaxConnections 5000
MaxConnIdleTime 900
MaxPageSize 1000
MaxQueryDuration 120MaxTempTableSize 10000
MaxResultSetSize 262144
MaxNotificationPerConn 5
MaxValRange 0

ldap policy: set maxpagesize to 3000
ldap policy: commit changes
ldap policy:

HeaderVar Not Showing Up Or Wrong Value

Have you ever had some header variables show up and not others? You think to yourself, " I must have a different authorization rules or expression that is being invoked and returning different headers." But when you go check in the Access Tester it is the rule that you are thinking of that is being tripped and there are no different actions on the authorization expression.

This is a peculiar problem that sometimes occurs and as near as I can tell this is what causes the problem. Why this seems to be the case, I have no idea. The problem occurs when one header variable name is competely encompassed in anothers name. For example the variable MYNAME is fully encompassed by MYNAMEPREFIX. If MYNAME comes first (or is it the other way around?) in the header variable list then strange things will happen and the results viewable in the header will not be what you expect .

There seem to be two resultions to this: (1) ensure the longer one shows up in the list first OR (2) given them completely disimilar names. I personally think that option 2 is the way to go. Option 1 can be fraught with more heartache if the orders get reversed down the road in a different environment.

I have only witnissed this behaviour on COREid 7 WebGate for IIS 5/6 . It has been repordoced accross separate installations. I have not tried to reproduce it elsewhere yet.

Disappearing Workflows During Horizontal Migration

If you work safely within the confines of the COREid Identity admin ui then you are protected by a friendly message that pops up when you add an objectclass to a tab. The message tells you that the operation will fail if you have any pending workflow tickets.

What happens behind the scenes as you add the new objectclass to the tab is that the system also adds the same objectclass to all the workflow definitions associated with that tab.

The take away here is that if you are manually migrating tab definitions from one environment into another you will break workflow definitions in the target environment if there is an objectclass difference contained in the new tab data. When this situation arises the rule is that the tab and all the workflow definitions for that tab must move as a unit.

[RFE]Regex Capturing In Policies - Nice to Have!

OK, so COREid supports rudimentary pattern matching in policy patterns. For instance, one can create a URL pattern in a policy definition that matches multiple URLs with a single policy (pattern). The following URL pattern matches the three separate set of subdirectories.

/applications/{app1,app2,app3}/.../*

This allows a company to set up a single policy for multiple resources that are not identical but have the same access rules. This can help to stem mass profilferation of policies in the system. Many policies can make it more difficult to administer a system. As well, the more policies that exist in a system the longer it can take COREid to evaluate which policy or policy domain matches a particular request as policies are always evaluated first.

This is great functionality, but it could be a lot more powerful with additional regular expression capabilities. I am not advocating dumping the way current pattern matching works to replace it with a veriosn of the full blown regular expression language many have come to rely upon. I expect features such as look ahead could have potentially disasterous results on the Access Server's ability to evaluate policies in a timely fashion. I do, however, think that adding a capturing feature would lend a powerful and useful capability without significantly degrading performance (then again I could be wrong).

Consider an instance whereby an authenticated user accesses a resource protected by an authorization policy with a URL pattern like the one above. What if there was a authorization rule that caught users that had not updated their profile to accept the latest terms and conditions. The authorization rule would have a action to redirect the user to the new Update Terms and Conditions function, but once they were complete the site would not know what resource to which the user had wanted to go originally. If regex capturing were introduced, however, COREid could capture and store the URL pattern that was matched. This is only part of the solution though; COREid would also need to make the captured pattern available to the authorization rule for use as a parameter in the action. This way the Update Terms and Conditions functionality could be configured to return the user to their originally requested URL.

Search Results Counter

Every COREid search creates a set of 0 to many entries. If you look in the XML, you can see that the system knows the size of the result set, but that it does not report it by default.
To display this data in style0, simply edit / identity /oblix /apps /common /bin /oblixappparams.xml and change the value of search_result_show_count to true.

Unable to initiate workflow Status Code 1

Ever get this message?
Unable to initiate workflow obworkflowid=96ab611fb664414abd219e7c1c4e6b92,obcontainerid=workflowdefinitions,ou=oblix,ou=apps,dc=dev,dc=company,dc=com. Status code 1.
When you get the status code of '1', chances are you are doing some manual LDIF migration activities and you accidentally lost the obWorkflowInstances container.