Re: Profile self-service

If you end up writing something yourself,  I would suggest you check out
using the EIM APIs and infrastructure as the basis for this -- even if
you're not using it for anything else.

If you decide you only want self-service reset and not full-blown identity
management,  you can use EIM as the repository for:
   those people allowed to reset their own passwords (which may be all
   employees, but maybe not) using EIM Identifiers
   a list of the user profiles that a person is allowed to attempt to reset
   the password for
   the personal questions -- and, if so inclined, the answers; otherwise
   the answers could be in a separate location.

The iNav user interface could be used to enter this information or you
could write your own app using the EIM APIs to manage it.

The reset program would look something like the following:
   Connect to EIM
   ask the person their name
   Use eimListIdentifiers() with the person's name as input (presumably,
   you would use their real name as the ID for the EIM ID)
   In the returned EIM ID structure will be the addl_info field which is
   where you would store the personal questions
   The addl_info entries would be added in some format you define such as:
   PersonalPasswordReset="what is your favorite pet's name"=encrypted
   answer (or else store the answers elsewhere and use the EIM ID and
   question as an index to find the answer. This is multi-valued field so
   you can have multiple questions....
   You can use the existance of personal questions to determine if this
   person is allowed to perform password self resets; OR you can have
   another addl_info entry like "PersonalPasswordResetAllowed/Denied" and
   look for that first.
   Or just let anyone that can answer questions do so...
   Loop through the addl_info strings looking for "PersonalPasswordReset"
   entries
   For each one found (or whatever algorithm you want to use; e.g. for
   three of the five found)
      display the question(s)
      get the answer(s)
      verify with the stored answer
   Use eimListAssociations() passing the same ID you passed to
   eimListIdentifiers, which returns the list of possible ID's that this
   person can reset.
   Loop through the returned data structure and display these names with a
   radio button or whatever you choose (select All?) and provide a field
   for them to enter the password
   Each association returned includes the userRegistryName (userID),
   userRegistryType, and the userRegistry.
   You can use the userRegistry value to find out information about the
   TCP/IP address and/or port of the userRegistry (assuming you added this
   optional information when the userRegistry was defined or sometime
   after).
   For the selected ID and provided password, use the TCP/IP address to
   find the system, based on the registryType, use an appropriate interface
   on that system to reset the password.  For OS/400 V5R2 or V5R3, I would
   suggest using the LDAP projected user profile backend to make the
   change.

You should be able to use iNav (or write a program to automatically create)
EIM IDs representing people, and create associations for the user IDs in
the various user registries in your network that represent them.  But you
will probably want a separate program that individuals use to establish
their questions.  You could write one by doing something like the
following:
   Ask the user to verify their local ID and password by providing it to
   the application.
   Verify that the password is valid for the userID.
   use eimGetAssociatedIdentifiers() using  the eim registry name for the
   local user registry and the local user ID
   Ask the user for questions and answers (or just the answers if you use
   canned questions)
   use the eimChangeIdentifier() with the EIM ID name found in the previous
   API call to add the questions and (perhaps after encrypting) add the
   answers.
Of course, you might also want the program to allow people to change their
questions and/or answers...this is left as an exercise for the reader...One
of the benefits you get by doing this, is that you now also have the EIM
info required to enable SSO for some or all of your applications -- at
which point you would be able to remove these passwords and not have to
have a password reset program at all -- you would still have to enable
Kerberos or some other external authentication mechanism to get SSO
working.

The axcessIT product happens to use EIM underneath the covers, so if you
want full-blown identity mapping, the axcessIT product also readies you for
SSO and it entirely hides EIM from you in the process.

I hope you're not sorry you asked :-)

Patrick Botz
Senior Technical Staff Member
eServer Security Architect
(507) 253-0917, T/L 553-0917
email: botz@xxxxxxxxxx