Exercise 4: Nicer Small Company
|Book reference||Chapter 4: Resources and Mappings, Chapter 5: Synchronization, Chapter 6: Schema, Chapter 7: Role-Based Access Control, Chapter 8: Object Template|
SynopsisSmall company with a nicer configuration: nicer usernames, database resource, schema, password policy, RBAC.
HR System: Employee data are stored in the HR system. There is an export task that exports the content of an HR system into a CSV file in regular interval.
Open source LDAP server (OpenLDAP, 389ds or similar): Company-wide LDAP server that is used as central user directory and authentication server for several applications. Accounts should be provisioned into the LDAP server using the standard
MidPoint: Start the exercise with an empty midPoint server.
CRM: Database-based CRM application. Accounts should be provisioned in the database table. See
create-table-crm.sqlfile. There are some pre-existing accounts, including some rogue accounts.
We have a small company. We have a simple HR system that exports the data to an CSV file. All the current employees are recorded in the HR system. There is also an LDAP server that works as central directory server. Many applications are configured to authenticate at this server using LDAP protocol. Our resident administrator is tired of managing LDAP accounts manually. Therefore we want to set up midPoint to automate this process.
Set up an synchronization task to pull the data from HR CSV file and provision accounts to LDAP server automatically. This setup should be based on previous exercise (see Exercise 3). But there are few changes:
Make sure that we have nice human-friendly usernames. Do not use employee numbers. Create some kind of algorithmic usernames based on user’s real name. Usernames such as
andersshould be acceptable, but do not make it too trivial.
Make sure that the username is unique. For example make sure that you can hire "Albert Anderson" and everything works.
Make sure that people can be renamed. If Alice gets married to Mr. Smith, make sure her username changes to
Make sure that renames are properly reflected in LDAP.
Connect the CRM resource to midPoint (e.g. use DatabaseTable connector). Set up the mappings. CRM is an "outbound" resource.
Be aware that you are not starting on a green field. There are some pre-existing accounts. Some of those accounts are legal, but they may not be configured in an entirely correct way. E.g. usernames may not match company standards. And then there may be accounts that should not be there.
Correlate existing accounts. It looks like employee number can be a reasonably good correlation identifier. Although, even that is not perfect. You may need to manually correlate an account or two.
We do not want to delete accounts on this resource. Accounts that should no longer be in the CRM system should be left in the CRM database, but they should be disabled.
Clean up the resource a bit and make sure that the resource stays clean. E.g. disable all illegal accounts and make sure that any new illegal account is automatically disabled. But do not overdo it. E.g. we want keep existing usernames for pre-existing accounts, even if they are not aligned with company standards.
There are job codes in the HR file. Let’s use them. Extend default midPoint schema with a new
jobCodeproperty and populate that from the HR file.
Create roles for every job code that is present in the HR file. Make sure those "job roles" are automatically assigned. You may need to extend default role schema to do that.
Do not repeat yourself. You could assign both the
Employeerole and the "job" role to the user. But that would be boring. We do not want to have two assignments when one is enough. Therefore make use of role hierarchy. We still want
Employeerole, we still want that role to contain LDAP account construction, but we do not want to assign that role to users directly.
You will have to figure out what to do with users that do not have a job code. You can either assign some default role to them. Or you can simply choose not to provision LDAP account to those people. Figure out something meaningful (but not too trivial).
Set up midPoint user interface to should custom view that contains active employees only. There should be a new "Active employees" menu item below existing "All users" item.
Set up the "job roles" to provision LDAP attribute
title. This attribute is multi-valued. While any person will normally have only a single "job role", make sure that the
titleattribute is properly provisioned with multiple values in case that a user has multiple job roles. Also make sure that midPoint is authoritative for this attribute. That means that any values that are assigned to the
titleattribute outside of midPoint control are removed.
Create a role catalog to organize the roles. Create some business roles that are suitable for ad-hoc assignment. Put them into the role catalog (there is no need to setup at an approval process yet). Make sure that those roles are properly "archetyped" using the pre-configured
Configure midPoint user interface to show "Business roles" menu item below existing "All roles" item.
Set up simple segregation of duties policy (SoD). For example make sure that
Controllingroles cannot be both assigned to one user at the same time.
Database schema for the CRM resource specifies maximum of 16 characters for the password. Although this is not ideal, we want a pragmatic solution here. Therefore set s company-wide password policy that specifies maximum of 16-character password. And let’s use this change to set up a strict password policy. Therefore set up a custom password policy, requiring minimal number of upper case letters, non-alphanumeric characters, password expiration and so on. This will be a really annoying policy that users will have in the real life. But hey, this is just an exercise. We can do that.
There are too many properties in default midPoint schema. We do not want to confuse users with the properties that we are not using. Therefore hide some of the superfluous properties, such as
organizationalUnitproperties of a user. Make sure they completely disappear from midPoint user interface.
Given name, family name and full name are such an important properties that we want to see them all the time, even if they do not have any value. Set it up.
There are properties that can be useful, but they have unusual labels in the user interface. E.g. we do not want to see "Family name". We want to see "Last name" instead. Make sure that it happens.
Our company has seven branches, one branch on each continent. Affiliation to a branch is stored in
localityuser property. But users are too tired to type
Antarcticato the text field. Make sure that there are pre-defined values for each continent for all users to choose from.
The process should be completely automatic. No administrator intervention should be needed. We still need initial passwords and all the other applicable things from previous exercises. We also want to be able to create contractors manually. Make sure it is still possible.