Friday, July 03, 2009

 

Introducing Stitcher - OAM Configuration Migration Solution

Many of our readers are aware that we have had the "COREid Migration Service" available for public use for the past three years. This service has been a resounding success with several high profile North American OAM customers relying on it to maintain consistency across their environments. The expression, "If it ain't broke, don't fix it." best describes our attitude towards the initial release.

But the time was right for a platform upgrade, some rebranding, and some minor issue fixes.

Stitcher lives at the same address as the original service. If it sounds like something you've been missing, check it out.

Labels: , , ,


Friday, June 12, 2009

 

Credential Mapping Error

Setting up IWA is a fairly straight forward task. All you need are an OAM environment, an IIS server with WebGate installed and special IWA Authentication Scheme. The IWA specific authentication scheme requires a credential mapping plugin to map the REMOTE_USER HTTP header variable set by IIS to a user attribute in the OAM user directory. WebGate even takes care of parsing the domain name from REMOTE_USER for you, what could be easier?

So assuming you followed all of hte instructions and everything is set up perfectly, or at least you think it is, what do you do if you still have a problem. Specifically, what could be wrong if are getting a credential mapping error in the web browser and the access server oblog.log file.

I recently encountered just such a problem. I used the search base and filter from the credential mapping plugin and conducted my own search against the directory as the OAM service account and it worked perfectly. This was so puzzling. I looked for trailing spaces in the credential mapping plugin because I know that can occur with resource patterns and ldap urls in other parts of Policy Manager. I finally compared a working credential mapping plugin to the IWA one. The different was in the quotation marks. The IWA credential mapping had been copied and pasted from the Metalink article discussing how to set up IWA in OAM. They were obviously from the wrong character set. Replacing the quotation marks solved the problem.

Labels: , ,


Wednesday, February 11, 2009

 

Panels in User Manager's Employees tab

The "Employees" tab of user manager can have multiple panels in it:
The header panel, the defaultPanel and any user defined panels appear under "obpanelid=Employees, obapp=userservcenter, o=Oblix,<Config Base>" in the LDAP as "obpanelid=<some timestamp as ID>".

The header panel has its obpaneltype value as "headerPanel".

The value of "defaultPanel" for obpaneltype is for the default user profile panel. The user can change its name from "defaultPanel" to any other value, but the obpaneltype remains "defaultPanel".
Ever wondered what the third panel type, obpaneltype of jCardPanel? Its the panel for the search results!

Just because it does not show up as a "panel" on Identity System console can sometimes create confusion. For example when once because of some buggy horizontal migration, we eneded up with two objects with obpaneltype=jCardPanel and any change we attepted on the user manager tab profile, resulted in the error "This panel is already configured". From the Identity System console we could not see any duplicate panel information, it was only when we looked closely in LDAP, we saw two objects with obpaneltype=jCardPanel. Once we deleted the un-needed object and restarted ois server, things started working.

Labels:


Wednesday, November 19, 2008

 

OAM Identity Server Deletes User When RDN Modified (on OID)

This is known problem but i had trouble finding the solution so here it is re-posted from the OAS release notes for HP-UX... the resolution worked perfectly BTW.

This problem occurs when you use Oracle Internet Directory as the back-end repository. To fix this problem:

  1. Edit the file ldapreferentialintegrityparams.xml in the following directory:

    Identity_Server_installation_directory\identity\oblix\data\common
  2. Change the value of the parameter referential_integrity_using from oblix to ds, as follows:

  3. Save the file.

  4. Restart the Identity Server for the changes to take effect.

    You should be able to modify the RDN attribute value without any problem.

  5. If you have multiple instances of the Identity Server installed, make this change to every instance of the Identity Server.


Wednesday, August 20, 2008

 

SDK-Access Server Time Difference Reminder

When using a older Access Server SDK (7.0.4) with a newer Access Server (10.1.4) running in backward compatibility mode recently, the Access Server SDK always returned cookies that were logged out. The reason turned out to be because the time was never set on the machine the SDK was installed on.

However, the Access Server SDK installed correctly when it was installed. In previous incarnations the Access Server SDK would have never been able to be configured properly if a significant time difference existed.

This definitely falls squarely in the realm of user error, as the documentation clearly stipulates that when cert or simple mode are used the times have to be synchronized between client and server. In previous releases though you would never have been able to complete the SDK configuration. I can only imagine this has something to do with "backward compatibility" mode.

Tuesday, August 19, 2008

 

IdXml Change Attribute WF Does Not Run

You create a change attribute workflow. Call it as a portal insert and it works. By work i mean updates the user's entry in the underlying directory when you change the value and click the save button in the OAM UI.

Having demonstrated successful configuration, your real objective is to invoke this through IdXml. So you create the IdXml and test it out. It seems to work, however, the attribute in the underlying directory is not changed.

It turns out if you cannot read the attribute you cannot request it to be changed via IdXml. However, it works if you request the change attribute using a portal insert instead. Sure enough if you test it with a canIRequestUserAttrModification request it will return Denied if you do not have read access.

This is an odd problem. And I am not going to dump any more time into it. But if you change the attribute so that the participant has read access on the attribute everything works as expected.

My specific situation involved a change attribute workflow where the participant was self.

Labels: , , ,


Thursday, August 07, 2008

 

Reactivate OAM User

In order to be able to search for deactivated users, the logged in user need to be a participant in a reactivate user workflow definition.

If the user is not a participant in a reactivate user workflow then the following message will be received when the "Deactivated User Identity" button is clicked:

You do not have sufficient access rights.

Labels: , ,


Wednesday, August 06, 2008

 

OID Indexes

Here are a few simple notes for handling OID indexes. If you want to search on an attribute in OAM where the data is stored in OID it must be indexed. Sometimes you might want to remove and then possible re-add an index. Index adding and removal can be handles with LDIF, however, if you need to recreate an index on existing data then you need to use a command line tool called catalog.

Index an attribute

dn: cn=catalogs
changetype: modify
add: orclindexedattribute
orclindexedattribute: attributename
-

Remove an index

dn: cn=catalogs
changetype: modify
delete: orclindexedattribute
orclindexedattribute: attributename
-

Re-index an attribute
that was previously removed. If you remove an index form an attribute and the data remains and you need to re-index the data in place then you need to use the catalog command line tool.

$ORACLE_HOME/ldap/bin/catalog connect=oiddev add=&quotTRUE" attribute="attributename"

Unwilling to perform
If after the attribute has been re-indexed the directory server will still not allow it to be searched and returns an unwilling to perform error, try restarting the OID gateway.

$ORACLE_HOME/opmn/bin/opmnctl restartproc ias-component=OID

Current Indexed Attirbutes
Use ldapsearch to get the current indexed attributes

ldapsearch -h localhost -p 389 -x -s base -b "cn=catalogs" "objectclass=*"

Labels: , ,


This page is powered by Blogger. Isn't yours?