At the University we have an in house developed identity management solution. Like many developments, it’s grown and grown to be much more than it was intended to be. Following a review we decided to replace the in house system and use SAP IdM instead. We’re currently in the first phase of a project to roll out IdM, the objective of this phase is to get information from HCM and our student record system and create user accounts (incl. email) in our AD domain.
This is my blog describing how we’ve built our dev environment.
h4. How does it work?
Here’s a quick run through of what i’ve learnt so far. Note: It’s not a standard Netweaver ABAP or Java stack and requires no prior knowledge of SAP to implement.
IdM is essentially a job ‘engine’ that performs tasks based on rules you define. It will get information from repositories, process the data based on the rules and jobs defined and then make updates in other repositories based on those rules.
The documentation has loads more information, but here’s my view on the five main components:
- Design Time: This is the Microsoft Management Console (MMC) interface which connects to the database. This is where you configure IdM. You can’t view any data from this console.
- Run time: The run time does the work. Basically it is the engine that processes the jobs defined in the MMC. It gets information from repositories, updates data in repositories etc.
- User Interface: This is a software component delivered via the Netweaver Java stack. Apart from directly querying the database, it is the only way of viewing identity data.
- VDS: Is a virtual directory that represents data from various data sources (directories, files, databases etc) and allows the data to be queried and updated via LDAP.
Here’s a quick overview of our landscape:
- IdM 7.1 SP5
- Database: SQL Server 2005 x64 on W2003 x64.
- Design Time: Runs on the main runtime server and a copy on each of the XP desktops of all IdM developer pc’s.
- Run time: We’re running two: SAP RT – W2003 R2 x64, AD RT – W2003 R2 x64
- UI: NW Java 7.01 EP (SQL Server 2005 x64, W2003 R2 x64)
- VDS: Runs on SAP RT.
The documentation is very detailed and there are full step by step instructions for the installation. Follow each of the documents to complete the install and the initial configuration guide details the steps needed to get all the components working together.
Initial Configuration: https://service.sap.com/~sapidb/011000358700001449642008E
The product documentation site has loads of detailed documentation showing how IdM can be configured to complete specific tasks.
Product Documentation: SAP NetWeaver Identity Management 7.1 Documentation
The installation process creates the database and schemas. We installed the database on an established development instance which it shares with other dev databases.
Notes: <u>Design Time</u>
This needs to run on a Windows pc (as it’s an MMC add in). We run a copy on the SAP RT server and a copy on each of the desktops of all IdM developer pc’s.
There doesn’t appear to be a way of controlling what someone can do once they have access to the MMC; it’s full control or no control. Need to think carefully about who has access to the system in the dev, qa and live environments.
We’re running two:
- SAP RT: This is responsible for the HCM connection to ERP and reporting integration with BW.
- AD RT: This server is part of the main AD domain and does user provisioning, email integration and file store.
We loaded the files as described in the documentation and it worked.
The UI can only ever point to one Identity Store. If you want to view other Identity Stores you’ll either need another UI or another method. When we were troubleshooting an issue with HCM integration we decided to use an LDAP browser to interrogate the HCM temporary identity store.
Virtual Directory Server
We’re using this to allow the transfer of data from HCM to IdM and from IdM to BW.