Beyond the Basics: An Overview of User LifeCycle and Managing Users with TDI

Beyond the Basics:
An Overview of User LifeCycle
and Managing Users with TDI
Michael Ahern | IBM Connections Developer | IBM

© 2011 IBM Corporation

Agenda
● Overview of Connections User LifeCycle

● User LifeCycle Architecture

● Overview of the Profiles TDI Solution

● Profiles TDI Connector Architecture

● Scenario based Demo

● Questions and Answers

© 2011 IBM Corporation 2

What is User LifeCycle?
● A number of other customers requested that the ability to retire or 'inactivate' users rather than being
required to delete them from the Profiles DB

● Profile types, provide a partial solution, but cannot deliver on full end-to-end including the UI
changes expected: indicating inactivity in membership lists, hiding them from name searches,
removing users from membership typeaheads etc and (most importantly) managing users in non-
Profiles components.

● Outside of inactivation, we were seeing a large number of operational issues in production with
managing user data across the platform. For example, there was no way to automatically
propagate name, email and external ID changes from Profiles to the other Connections
components.

● What was delivered:
─ User state and other relevant data will be communicated from Profiles to the rest of the
Connections platform
─ All Connections Application UIs will reflect and indicate the 'state' of the user
─ Inactive users do not show up in a 'default' Profiles name / advanced searches


Contrast of User Populations Pre/Post 3.0.
● This slide captures how the user population of the Connections system
compares and contrasts between <3.0 and 3.0+

The World Before 3.0 The World 3.0 and beyond

All Users Ever All Users Ever

Users in Profiles DB

Users Users
Active Users / App 'X' Active Users App 'X'
Users in Profiles Knows Knows
DB


Active vs. Inactive User Member Tables
● When a user changes state, the member and login tables need to be updated
to prevent data constraint issues later on.

Active User Inactive User
MEMBER TABLE MEMBER TABLE
Column Example Value Column Example Value
InternalId 12345... InternalId 12345...
DisplayName Mike Ahern DisplayName Mike Ahern
Email ahernm@us.ibm.com <NULLED> Email <NO VALUE>
ExternalId abc-foo-1234.. ExternalId abc-foo-1234..
State 0 State 1

LOGINS TABLE TABLE LOGINS TABLE TABLE
Internal-ID Login <NULLED> Internal-ID Login
12345... ahernm@us.ibm.com <NO VALUE> <NO VALUE>

12345... ahernm


User LifeCycle Architecture - Commands
● User LifeCycle is implemented by a set of discrete 'platform commands' that
allow you to drive user data changes from Profiles across the platform.

● These commands are executable via TDI; the Admin ATOM API and wsadmin.
In addition, each of the components has matching wsadmin commands to allow
you to correct data in an individual component.

● Platform Commands:
Command Description
Update User Update user data
Publish User Data Publish the current user data from Profiles
Inactivate User Inactivate user
Activate User Activate / reactivate a user
Swap User Access Allows you to restore a users content and
inactivate their 'phantom' Profile record


LifeCycle Architecture – Platform Command (SEND)
Consuming
Component
TDI Process
Profiles TDI
ProfilesDB
Connector

Event
LDAP Infrastructure

Profiles Server

Synchronous Event News Server
Profiles Admin Augmentation (such
API Caller as Audit)

Profiles Admin
3rd Party Event
API Caller
SPI


LifeCycle Architecture – Platform Command (ACK)

Consuming
Component Event Infrastructure

Synchronous Event
Augmentation (such
as Audit)

News Server
Component
DB
Future 3rd Party
Monitoring App?


What is Tivoli Directory Integrator
● IBM Tivoli Directory Integrator is the “Norwegian army knife” of data synchronization. It
is software that synchronizes data across multiple repositories. TDI can connect and
transfer data from and to:
─ LDAP directories
─ Domino databases
─ Relational Databases
─ And much more . . .

● A unit of work in TDI-speak is called an Assembly Line (AL) and Assembly Lines are
made up of a set of components known as 'Connectors' which read / write and / or
transform data
● Connections ships with a number of 'out-of-the-box' AL's for synchronizing LDAP data
with Profiles.

source
source Target
source
(Profiles)
TDI


Fitting the Pieces Together: Scripting
● For 3.0 the major objectives of TDI has been in improving maintainability of the
system and providing customer tooling and extension points to cover functional
gaps not filled by the core product.

● Major functions:
─ Source Repository Connector
─ Custom delete logic hook
─ Improved Logging
─ And...

● The Profiles TDI Connectors
─ The TDI Connectors is the formalization of the interface to the Profiles backend
─ The Connector allows you to script and interact with the Profiles DB via the TDI
scripting editor
─ The Connectors are fully integrated with User LifeCycle, allowing you to push data
changes to the Connections Platform


Under the Hood: Connector Details

Connector Details
EMPLOYEE SURNAME
- During read / create /
Table Table
update of profile records
all four tables are merged
into a single logical TDI
entry
- During deletes, TDI will Profile TDI DYNA_ATTRS
touch and remove content Connector Table
from all of the tables
associated with a user GIVEN_NAME
(PROF_CONNECTION, Table
PEOPLE_TAG, ETC) Additional
Tables

PROFILE_EXTENSIONS
PROFILE_LOGIN Table
Table


Demo: The Connector In Action
Scenario 1: Migrating users to a new LDAP

PROBLEM: The IT department is in the process of reoganizing the LDAP
directory. As a result of this action the external ID (GUID) will change for all users
in the system.

SOLUTION: Assuming the 'uid' (the company assigned unique identifier for the
user) has not changed during the migration, run 'sync_all_dns'. Profiles will
propagate the changes to the platform


Scenario 2: Normalizing values in the 'uid' field of Profiles

PROBLEM: At company X Ops recently realized that their LDAP contains
inconsistent data for 'uid'. Different 'casing' is used for different users and in some
cases there are even trailing spaces after names! In parallel to cleaning up their
LDAP they wish to normalize the data in Profiles to remove inconsistencies.

SOLUTION: Create a custom script.


Questions?


Legal Disclaimer
© IBM Corporation 2011. All Rights Reserved.

The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without
warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of
the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors,
or altering the terms and conditions of the applicable license agreement governing the use of IBM software.

References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change
at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor
shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results.

IBM, the IBM logo, Lotus, WebSphere, Rational, Rational Jazz and Lotusphere are trademarks of International Business Machines Corporation in the United States, other countries, or both.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

All references to Renovations refer to a fictitious company and are used for illustration purposes only.


References
● User LifeCycle:
http://www-10.lotus.com/ldd/lcwiki.nsf/dx/Managing_users_ic301
http://www-10.lotus.com/ldd/lcwiki.nsf/dx/User_life_cycle_details_ic301
http://www-
10.lotus.com/ldd/lcwiki.nsf/dx/Managing_user_data_using_Profiles_administrative_commands_ic301
http://www-10.lotus.com/ldd/lcwiki.nsf/dx/Troubleshooting_the_user_lifecycle_SPI_ic301

● Learning TDI:
http://www.tdi-users.org/twiki/bin/view/Integrator/WebHome
http://www.tdi-users.org/twiki/bin/view/Integrator/LearningTDI

● Connections / TDI:
http://www-
10.lotus.com/ldd/lcwiki.nsf/dx/Developing_custom_Tivoli_Directory_Integrator_assembly_lines_for_Pro
files_ic301
http://www-10.lotus.com/ldd/lcwiki.nsf/dx/Setting_up_your_development_environment_ic301
http://www-10.lotus.com/ldd/lcwiki.nsf/dx/Using_a_custom_source_repository_connector_ic301


Backup – Iterator Mode
 Iterates through the Profiles database
– no input settings required
– returns all Profile data, including extension attributes


Backup – Update Mode
 update via link criteria
 Set data to be updated


Beyond the Basics:
An Overview of User LifeCycle
and Managing Users with TDI
Michael Ahern | IBM Connections Developer | IBM

© 2011 IBM Corporation

Hello, my name is Michael Ahern... I am a developer
with IBM Connections in Dublin. Prior to moving to
Dublin earlier this year, I was the development lead
for the Connections Profiles component and have
been working on Connections in some shape or form
since 1.0.

Talk today: on the new user management features in
Connections 3.0 known as user life cycle and how
this integrates together with the new features in the
Profiles TDI component.

EMAIL: michael.ahern@ie.ibm.com

NOTE: Some slides are not created equal. Please
excuse some of the terser comments.

Agenda
● Overview of Connections User LifeCycle

● User LifeCycle Architecture

● Overview of the Profiles TDI Solution

● Profiles TDI Connector Architecture

● Scenario based Demo

● Questions and Answers


The agenda for today is...

To give an overview of what User LifeCycle is and an
architectural background into its functioning.

I'll then switch over and do the same for the Profiles
TDI solution and then finally tie the together with a
couple of illustrative examples.

What is User LifeCycle?
● A number of other customers requested that the ability to retire or 'inactivate' users rather than being
required to delete them from the Profiles DB

● Profile types, provide a partial solution, but cannot deliver on full end-to-end including the UI
changes expected: indicating inactivity in membership lists, hiding them from name searches,
removing users from membership typeaheads etc and (most importantly) managing users in non-
Profiles components.

● Outside of inactivation, we were seeing a large number of operational issues in production with
managing user data across the platform. For example, there was no way to automatically
propagate name, email and external ID changes from Profiles to the other Connections
components.

● What was delivered:
─ User state and other relevant data will be communicated from Profiles to the rest of the
Connections platform
─ All Connections Application UIs will reflect and indicate the 'state' of the user
─ Inactive users do not show up in a 'default' Profiles name / advanced searches


Customers requested...

Profiles types provides partial. Issues:
* No visual indication outside of Profiles
* Users in membership typeaheads
* Notifications

Contrast of User Populations Pre/Post 3.0.
● This slide captures how the user population of the Connections system
compares and contrasts between <3.0 and 3.0+

The World Before 3.0 The World 3.0 and beyond

All Users Ever All Users Ever

Users in Profiles DB

Users Users
Active Users / App 'X' Active Users App 'X'
Users in Profiles Knows Knows
DB


Slide showing comparison of users known by system
in 2.5 vs 3.0.

● In 2.5 Profiles contains only 'active' users and the
entire active population.
● Components contain a subset of Profiles + inactive

users that have used the component, but are now
inactive

● In 3.0+ Profiles contains the total population of active
users + the population a subset of the inactive user
population that has been inactivated since 3.0+ was
installed.
● Components may contain additional inactive users

that Profiles is not aware of.

Active vs. Inactive User Member Tables
● When a user changes state, the member and login tables need to be updated
to prevent data constraint issues later on.

Active User Inactive User
MEMBER TABLE MEMBER TABLE
Column Example Value Column Example Value
InternalId 12345... InternalId 12345...
DisplayName Mike Ahern DisplayName Mike Ahern
Email ahernm@us.ibm.com <NULLED> Email <NO VALUE>
ExternalId abc-foo-1234.. ExternalId abc-foo-1234..
State 0 State 1

LOGINS TABLE TABLE LOGINS TABLE TABLE
Internal-ID Login <NULLED> Internal-ID Login
12345... ahernm@us.ibm.com <NO VALUE> <NO VALUE>

12345... ahernm


In certain orgs email / login Ids are reused after a
period of inactivity (this happens at IBM for instance).
To prevent this from causing operational issues, the
login ID(s) and email address are blanked to allow
their reuse.

Not blanking the fields can prevent new users from
being able to access the system due to ID clashes
between the active & inactive users. In more
extreme cases, the clashes can result in data
leakage if system admins accidentally reactivate the
old user's account in order to allow the new user to
log into the system.

LifeCycle Architecture – Platform Command (SEND)
Consuming
Component
TDI Process
Profiles TDI
ProfilesDB
Connector

Event
LDAP Infrastructure

Profiles Server

Synchronous Event News Server
Profiles Admin Augmentation (such
API Caller as Audit)

Profiles Admin
3rd Party Event
API Caller
SPI


This picture shows the parts of the pieces of the
Platform Command architecture.

1. Events are generated in TDI or an Admin API
process.

2. Changes are queued up in a staging table in Profiles
(USER_PLATFORM_EVENTS) for publication.
Within Profiles, the changes are seen immediately.

3. Changes is published via the Event Infrastructure to
the Connections platform

4. Consuming Components (Blogs, Communities,
Files, etc) process the commands.

LifeCycle Architecture – Platform Command (ACK)

Consuming
Component Event Infrastructure

Synchronous Event
Augmentation (such
as Audit)

News Server
Component
DB
Future 3rd Party
Monitoring App?


In addition to the command message, there is an
acknowledgement. Currently no action is taken on
the acknowledgement.

The intention is to ensure that there is an auditing trail
of each components response to the command. If
no applications are subscribing to the message, the
infrastructure will not publish the message to reduce
the system load.

In the future it is hoped that an ISV or ISSL may build a
monitoring application utilizing the command
acknowledgement to alert admins as to the platform-
wide result of their commands.

What is Tivoli Directory Integrator
● IBM Tivoli Directory Integrator is the “Norwegian army knife” of data synchronization. It
is software that synchronizes data across multiple repositories. TDI can connect and
transfer data from and to:
─ LDAP directories
─ Domino databases
─ Relational Databases
─ And much more . . .

● A unit of work in TDI-speak is called an Assembly Line (AL) and Assembly Lines are
made up of a set of components known as 'Connectors' which read / write and / or
transform data
● Connections ships with a number of 'out-of-the-box' AL's for synchronizing LDAP data
with Profiles.

source
source Target
source
(Profiles)
TDI


* Norweigen army knife of data sync

* Loads / transforms data

* Unit of work AL

* Connections provides a group of AL's (a solution) for
synchronizing data with Profiles

Under the Hood: Connector Details

Connector Details
EMPLOYEE SURNAME
- During read / create /
Table Table
update of profile records
all four tables are merged
into a single logical TDI
entry
- During deletes, TDI will Profile TDI DYNA_ATTRS
touch and remove content Connector Table
from all of the tables
associated with a user GIVEN_NAME
(PROF_CONNECTION, Table
PEOPLE_TAG, ETC) Additional
Tables

PROFILE_EXTENSIONS
PROFILE_LOGIN Table
Table


Admins should never (or as rarely as possible) modify
Dbs directly. In reality (especially with user data)
there are special cases where this is a necessary
function.

As the complexity grows (as here), it becomes
essentially impossible to make manual modifications
in a manner that maintains DB integrity.

The Connector solves this situation of having to
understand the schema, but providing a stable
flattened data view.

Scenario 1: Migrating users to a new LDAP

PROBLEM: The IT department is in the process of reoganizing the LDAP
directory. As a result of this action the external ID (GUID) will change for all users
in the system.

SOLUTION: Assuming the 'uid' (the company assigned unique identifier for the
user) has not changed during the migration, run 'sync_all_dns'. Profiles will
propagate the changes to the platform


Scenario one is a trick problem... LifeCycle combined
with TDI should handle this seamlessly in most
organizations.

Scenario two, is a simple problem, however pre-3.0 it
was fairly complicated to execute this form of data
change. In the field I have seen organizations spend
man-weeks (sometime months) preparing for and
executing data changes like this. One customer
actually sent me a 40 page document describing the
procedure the ops-team intended to implement to
solve this problem.

These problems can now be solved in man-days and
with a far higher degree of reliability.

Scenario 2: Normalizing values in the 'uid' field of Profiles

PROBLEM: At company X Ops recently realized that their LDAP contains
inconsistent data for 'uid'. Different 'casing' is used for different users and in some
cases there are even trailing spaces after names! In parallel to cleaning up their
LDAP they wish to normalize the data in Profiles to remove inconsistencies.

SOLUTION: Create a custom script.


Scenario one is a trick problem... LifeCycle combined
with TDI should handle this seamlessly in most
organizations.

Scenario two, is a simple problem, however pre-3.0 it
was fairly complicated to execute this form of data
change. In the field I have seen organizations spend
man-weeks (sometime months) preparing for and
executing data changes like this. One customer
actually sent me a 40 page document describing the
procedure the ops-team intended to implement to
solve this problem.

These problems can now be solved in man-days and
with a far higher degree of reliability via a single-pass
script rather than via the 10+ wsadmin commands it
took previously.

Beyond the Basics: An Overview of User LifeCycle and Managing Users with TDI

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Beyond the Basics: An Overview of User LifeCycle and Managing Users with TDI

Similar to Beyond the Basics: An Overview of User LifeCycle and Managing Users with TDI (20)

More from Stuart McIntyre

More from Stuart McIntyre (20)

Recently uploaded

Recently uploaded (20)

Beyond the Basics: An Overview of User LifeCycle and Managing Users with TDI