If the manager fails to write down the password or remember what was generated and displayed on the screen before the user object got checked in then he would need to reset the password again to a new random value.

But there is another scenario, where you “need” the password: when you need to distribute the password (to user’s manager, to help desk people, etc.). Sure, this is not really secure, but you user has to login to IdM or Windows somehow… The first password must be known.

I don’t even use IDM as a login module. I do pass-through authentication to an LDAP server which does store passwords in a safe format. IDM isn’t even part of the login module group so when a user changes his password in IDM the Lighthouse resource password is not updated.

So, yes, what that means is when a user is provisioned into a new resource then they either have to change their password through IDM to make all resource passwords in sync. However, usually that isn’t necessary, we use single-sign on which in turn uses the LDAP resource’s password, which is safely hashed. But that’s not something that happens every day. It’s rare that a user has an account provisioned more than once a year.

We’ve sacrificed the convenience of instant provisioning for security. 95% of the time single sign on hides that inconvenience, but not always.

Or are you suggesting that every time a user receives a new account, they should have to change their password?

Nice post.. I’d like to add one thing though:

listAll is I believe the single most important resource action, but I believe it is not used correctly everywhere.. For example, before I was mingling with it, the procedure was used to list only all the users in the resource only. However, it can and it must also be used to list available resource user attributes such as all available roles and any other objects for that matter.. This way Sun IDM is able to cache the retrieved data and use it later.. Performance increase in a nutshell..

Could you also advise on which adapters you use for Web Services? (SOAP or REST?) Scripted Shell or Scripted JDBC as well?

Ah, the poorly undocumented viewOptions map… Ok, I agree, it can be done with forms. You need to make sure feedop is being set correctly, which likely means you need a delete rule in your AS configuration and that’s assuming IDM can even tell the difference between a create and an update. It’s not always possible for it to make that determination so everything shows up as an update feedop.

My personal preference is still to use the process rule/workflow. The delete rule, confirmation rules, correlation rules, input form and then still yet another set of workflows each of which should have proper error handling in them… all of which assumes you’ve also only got one type of object, a single user, to update. Maybe I’m just a sucker for simplicity.

<Field name="viewOptions.Process">
    <Expansion>
        <switch>
            <ref>feedOp</ref>
            <case>
                <s>create</s>
                <s>WF-Sync-Create</s>
            </case>
            <case>
                <s>update</s>
                <s>WF-Update</s>
            </case>
            <case>
                <s>error</s>
                <s>WF-Sync-Error</s>
            </case>
            <case>
                <s>delete</s>
                <s>WF-Sync-Delete</s>
            </case>
        </switch>
    </Expansion>
</Field>

In above example; activesync feedop value is referenced to identify the type of action – create, update, error or delete and viewOptions.Process is set to different workflows to be called by a “switch-case” usage.

About backward compatibility: The IDE will continue to be compatible with older versions of IDM. The much requested feature to detect the state of a configured app server (e. g. if it has been started by some means outside NB) will make it much less likely for a plugin built against NB 6.5.1 to work with 6.8 without change, though.

If you pass generatePassword a nonexistant policy name it returns null

Policy
policyName

Actually whether or not the indexes are a problem is likely dependent on what version of Oracle you use. I probably forgot to mention that.

I started with Oracle 9 as my IDM repository a while back and went through several upgrades since then. Reversing the indexes early on in my IDM life resulted in a huge boost. It was also recommended by our professional services people too.

I guess it’s not really necessary anymore and has been part of my superstitious performance tweaks since then. (As is my daily ritual of waving a rubber chicken and dancing in a circle in the morning to appease the performance gods. )

Even Sun has fixed the generation unique identifies in the database to be more random with the first few characters as of a recent 8.1 IDM patch. But heck, I’ll take whatever tweaks I can get!

I wish we had seen this post before we spent a week tracking down the same problem last month. We were running fine for a while, then one day our sync workflow ground to a halt. It was processing 1 record every 45 minutes until we resolved the issue.

But a clarification: our testing indicates that the reverse indexing isn’t what fixed the problem. Whether we use the forward or reverse index (which we didn’t think to try until reading this article) we see the same poor performance. For us the “size=1″ change actually fixes the problem, even without using the reverse index.

[The rest of this is explanation of the details of why the stats gathering is causing problems, but isn't important unless you care about the "why", and how the problem manifests under the covers....]

The actual Oracle indexes themselves show the correct number of distinct values in the columns whether you use the forward (normal) or reverse index; they are not “losing” data. The problem is in the Oracle statistics gathering, which creates histograms for the optimizer to use when running queries. The statistics gathering process that only looks at the first 32 bytes of the data in a column when profiling your table, which means that the histograms have the bad data, not the indices.

Note that the stats gathering process only creates histograms when certain table statistics thresholds are met, so this problem can just suddenly occur one day (as it did for us) when those internal conditions are met.

Based on our DBA’s tests, even when using a reverse index on the table, the statistics gathering still looks at the sequentially first 32 bytes when creating the histogram, so the histogram data we get is still wrong. The bad histogram causes a problem because when Sun IM does user searches, it’s fairly standard to see a query like this:


SELECT userobj.id, name, '', '', summary, '' FROM waveset.userobj WHERE name!='LASTMODIFIED' and name NOT LIKE '#DEL#%'
and userobj.id IN ( select id from waveset.userattr where attrname='YOUR_SEARCH_ATTR_NAME' and attrval='YOUR_SEARCH_ATTR_VALUE' ) order by name


If you manually run this query the “correct” way:

(1) run the “interior” (userattr) query
(2) replace the SQL for the interior query with the results and run the exterior (userobj) query

the execution time (not counting your typing) is very fast, even with neither fix in place.

The problem is that when creating the execution plan for the combined query, the Oracle optimizer looks at the histogram data for the user table and NOT at the number of distinct values in the table itself. Because the histogram says there are only a few distinct values in the userobj table — in our environment the histogram data was off by a factor of about 1000 — the optimizer decides to execute the outer query first (returning ALL users), then joins the results to the userattr table to perform the inner query.

By joining all userobj entries to all userattr entries you end up with a colossal result set — count(userobj)^2 * (# of indexed attributes/user) — and performance comes to a screeching halt.

By setting the “method_opt=>’FOR ALL COLUMNS SIZE 1″ argument in the stats gathering, you are basically telling the stats gathering not to create the histogram data, so when the optimizer goes to build the execution plan it must look directly at the index to retrieve the number of distinct entries, instead of looking at the histogram statistics describing the index. It then sees the actual number in both tables, and creates a more rational execution plan.

Again, the end result is the same (bad performance), and the stats fix you list is what we came up with too, but the Oracle issue isn’t as bad as “Oracle indexes are wrong”. Turning off the histograms probably has some side effect on optimization, but it’s certainly better than the performance hit this problem causes. It’s also possible to just remove the histograms on the affected (ID) columns, though that’s more work

Best regards,

Having said that, as you’ve pointed out it was a bit of an anticlimax. As with much of the documentation, the javadocs provided next to no help!