Question regarding unique user identification

[Former Member]

Hi everyone

I haven't managed to find a way to uniquely identify a user within the UME, and was hoping someone could help with this. Here's a brief scenario to explain the problem:

Simon Jones joins the company and is given username sjones. He is given access to various application within the Java AS (including Portal and some custom applications). Some time later, he leaves the company and his user account is deleted.
Steven Jones joins the company a year later, and is given the username sjones (same username as Simon Jones had when he was employed). He is given access to different functionality within Portal and the same custom applications.
The custom applications each store custom user-specific information in their own tables.

Now here's the question. How do the custom applications store information relating to the user, ensuring that it is uniquely assigned to that specific user and not to any future users that are created with the same username? In other words, is there a unique key (similar to the SID in Microsoft Active Directory) that uniquely identifies the user, and can be used as the key in the custom tables described above? This would need to be a new key generated for each user as they are created - ensuring that two users with the same username (existing at different times) are uniquely identifiable.

Or is there perhaps a place where custom information can be added to the user record in the UME in a generic way (i.e. does not require any schema changes)?

I realise I may not have explained this very well, so please ask if anything is unclear.

I'd really appreciate some comments on this.

Thanks

Stuart

[Former Member · Accepted solution]

Hi Stuart,

the UME API supports so called custom attributes that are written to the database without the need for any UME persistence configuration change (see code example below). If you don't mind UME persistence configuration changes and such an attribute is already available in the user objects (e.g. because they are read from an LDAP directory server which generates such identifiers during user creation), you can also change the UME persistence configuration and add new attributes on your custom namespace that are mapped to the physical attribute of the LDAP user object that contains the identifier.

Regards,

Uwe

Code example:

        // define the name space and the attribute name which sould be used to store and read the unique ID
        String namespace = "com.mycomp.mydepartment";
        String attribute = "unique_user_identifier";

        // read the logged in user
        IUser u = UMFactory.getAuthenticator().getLoggedInUser();

        String uniqueUserIdentifier = null;

        // read the identifier
        String[] uniqueIdentifiers = u.getAttribute(namespace, attribute);
        if (uniqueIdentifiers != null && uniqueIdentifiers.length == 1) {
            // identifier already stored
            uniqueUserIdentifier = uniqueIdentifiers[0];
        }
        
        if (uniqueUserIdentifier == null) {
            // no identifier stored (e.g. newly created user)

            // read the user factory
            IUserFactory uf = UMFactory.getUserFactory();

            boolean done = false;
            while (! done) {
                // use any suitable algorithm that creates a String identifier with less than 255
                // unicode characters.
                uniqueUserIdentifier = java.util.UUID.randomUUID().toString();

                // request a mutable user object
                IUserMaint um = uf.getMutableUser(u.getUniqueID());
                // set the new identifier
                um.setAttribute(namespace, attribute, new String[] { uniqueUserIdentifier });

                // persist the changes
                um.save();
                um.commit();

                // check whether the identifier identifies exactly one user (same identifier can be
                // created on a different server node in the cluster.
                IUserSearchFilter usf = uf.getUserSearchFilter();
                usf.setSearchAttribute(namespace,
                                       attribute,
                                       uniqueUserIdentifier,
                                       ISearchAttribute.EQUALS_OPERATOR,
                                       true);
                ISearchResult sr = uf.searchUsers(usf);
                int counter = 0;
                while (sr.hasNext()) {
                    sr.next();
                    counter++;
                }
                done = counter < 2;
            }
        }

Edited by: Uwe Steigmann on Sep 11, 2008 3:06 PM

Edited by: Uwe Steigmann on Sep 11, 2008 3:07 PM

[Former Member · Accepted solution]

Hi Uwe

Thanks for your response. That's really useful info!

I assume from your reply that SAP does not provide a truly unique identifier for each user? This is not something I would like to create myself, as it can then easily be overwritten, and would then add no value. I will definitely use the attributes for other user-related information that I'd like to store, so the code sample you provided is still very helpful to me!

It's a pity SAP didn't provide proper unique user identification, especially seeing as they had so many good examples of user management systems as a reference point for their design (including Microsoft Active Directory, Novell Directory Services, Open Directory, OpenDS, etc.).

[Former Member · Accepted solution]

Hi Stuart,

no, SAP does not provide an identifier which is also unique over time. As long as the users are maintained via the UME API, there will be no issu with recreated users, as all user related data will be removed from the SAP system during deletion. If the user is deleted and created in an connection LDAP directory server, the UME consistency check tool can be used to cleanup pending data.

If such an attribute exists for a user in an LDAP directory, it can simply be requested via the UME API by adding a new UME attribute to the UME data source configuration file and mapping it to the physical attribute name of the attribute in the LDAP directory.

BTW: Having identifiers that are unique over time also brings some problems, especially if the LDAP vendor or persistence option is changed, as any data that is assigned to users could then be lost.

Uwe