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

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!

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


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.

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.

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.

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.

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 120
MaxTempTableSize 10000
MaxResultSetSize 262144
MaxNotificationPerConn 5
MaxValRange 0

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

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.

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.

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.

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.

Permalink posted by Mark Miller @ 1:18 p.m. 0 comments

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.