Identity Manager is a web based application and therefore requires a Java Enterprise architecture
It requires basic Software Requirement like ,
JDK - JRE
Repository (DATABASE)
Application Server
Net Beans - IDE
Directory Servers
JDBC - Connector
Setting up development environment for an Identity Manager project -- ???
Everything is installed into a Vmware Image that can be downloaded and used as a starting.
Architecture of the IDM
Identity Manager is an integrated solution for user provisioning and synchronization in heterogeneous environments, Sun Identity Manager covers the whole life cycle from creation to termination of an user account. The architecture is very open and extendable, Identity Manager consists of a kernel written in Java and a bunch of servlets and JSP's that are forming the user interface. The main component of the kernel is an XML interpreter, as everything is described in form of XML objects. Besides that, the kernel is basically a workflow and rendering engine
whole system is based on XML objects of different types. These objects are stored in a database the so called repository.
Resources
A system for user provisioning only makes sense, if the managed data can be read and written from whatever system is involved. In the context of the Identity Manager these systems are called Resources. Resources come in different flavors. They can be as simple as a text file spanning over directory servers up to full fledged enterprise resource planning systems. The requirements of every system are of course different, but inside Identity Manager they are hidden beneath a unique abstraction layer. The most prominent resources are Active Directory, SAP HR, SAP R3 and LDAP, more you can find in Resource Refrences of Sun IDM Documentation in this link http://docs.sun.com/app/docs/doc/820-6551?l=en&q=sun+idm+8.1
For connecting this resources to the system so called drivers or adapters are needed. These are software packages of Java classes that implement everything needed to talk to the resource. Usually they are available as so called jar files (Java Archive). It's a simple archive containing all the necessary files. In most cases they are developed by the vendor of the resource and are available for download on the vendor's website.
Web Application
As a web application the Identity Manager needs a runtime container. This container implements several well defined public API's. Utilizing these API's the applications have access to services like database or directory access, authentication, authorization and session services. Java based application server are available in two different flavors. The full fledged J2EE application servers and the light weight servlet containers. A short introduction into the J2EE architecture can be found http://java.sun.com/j2ee/overview.html
A servlet container basically implements the Java Servlet and Java Server Pages API. A J2EE server in contrast must implement every aspect of the J2EE API. Therefore it incorporates a servlet container, but supplies additional services to the applications. Tomcat from the Apache Software Foundation is the reference implementation of a servlet container. Glassfish developed by Sun Microsystems is the reference implementation of a J2EE Application Server.
The Identity Manager relies on a servlet container and does not need any service of a real application server. Therefore a servlet container like Tomcat is sufficient. Nevertheless the usage of a full blown Application Server like glassfish come with advantages in handling and monitoring.The supported container can be looked up in the document IDM_Installation and the Release Notes
File Structure
A web application consists of HTML pages, images, JSP Files, servlets and Java Code. The Java Code very often is organized into JAR files (Java ARchive) - the Java Version of a library. The files are stored in a hierarchical directory structure and simply archived in a single file. All files together form the web application. To ease the handling everything is bundled into a single WAR file (Web Application Archive).
Servlet and application server know how to deal with files like that.The directory structure of the Identity Manager web application is layed out as followed
account : jsp directories :
The file Waveset.properties located in the /config directory contains the base config of the system.Modifications on this file therefore needed a restart of the application server or at least the application server container.
system kernel is stored as several jar files in the directory /WEB-INF/lib,
archives forming the core IDM application there are others that are needed by the core, but are developed by 3 rd party. Additional drivers for accessing the different types of repositories also have to be stored in this directory. One example is the file mysql-connector-java-5.0.5-bin.jar, which is the jdbc driver for accessing the MySQL database.
Depending on the application server of choice this is also the directory to supply the activation and mail framework. Simply store the files activation.jar and mail.jar in this directory.
If you ever want to develop your own Java code, it can be stored in the same directory bundled as a jar file. Alternatively your classes can be placed in the directory /WEB-INF/classes without being organized into a jar file.
If the IDM IDE is being used, the compiled Java classes are by default placed into this directory. A javadoc based documentation of the Identity Manager Java classes can be found in the REF Kit of the distribution package.
JSPs
The IDM root and several sub directories are holding the IDM JSP files (Java Server Pages). The files forming the enduser interface are by example located in /user.Customizations of the enduser interface are usually realized by modifying the CSS files in /styles Most of the time the JSP files don't need to be touched.Still, if the flexibility of the CSS files are not sufficient, the jsp files have to be changed. Unfortunately simply renaming the files that have been modified is not possible. In various files the name of the jsp files to be called are hardcoded. If you start modifying file names all referencing files have to be touched.
Identity Manager is basically a set of Java code forming a run time system, consisting of different engines and a large number of helper classes. The whole configuration and every other aspect of the Identity Manager is defined utilizing XML Objects. There are for example User Objects or Resource Objects. These files are interpreted by the engines of the Identity Manager, remodeled into Java objects and used to build the system.
For every resource that should be connected Identity Manager needs code to talk to the system, that are the Java based adapter classes mostly in the form of Jar files. Besides the implementation a system to be connected has to be configured. This is done by defining an XML object of type ResourceType.
The attributes of this resource type just describe more aspects of the system. Examples are the name or the proxy user credentials for accessing the system. The main information is basically the class name of the java classes that build the driver. Given this information the Identity Manager knows, which code to call, if a component wants to access the system. This behavior is called Late Binding and bridges the gap between the XML objects and the Java code.
Besides resource definitions the XML objects define the user forms (HTML pages), workflows, even user and much more. These XML objects are stored in the IDM Repository. Modifications and enhancements are done by altering these objects in the repository. The initial state of every object in the repository can be rebuild by cleaning the repository and reimport every single XML file from /samples. Besides the initial seeding of the repository this directory is a valuable source for examples of how to work with the different aspects of Identity Manager. Simply copy and modify the files to your needs. After reimporting the file into the repository your modifications are in place.
Repository
The Identity Manager repository is the single location, where all the XML artifacts are stored. Additionally all log information is stored in it as well. If a workflow has to be suspended, because an approval is pending, it is persisted in the repository. The repository is the single most important part of the Identity Manager, if it is not available, the Identity Manager can't start up. To access the repository a JDBC driver is needed, the same technology which is used for accessing every other resource database. The supported repository databases are listed in IDM_Installation and the Release Notes. Note that not all databases that can be used as a resource are also supported as repository.
The Identity Manager must know, what repository to access while starting. This information is read from the configuration file /WEB-INF/ServerRepository.xml. This file is created using the lh setRepo command
The size of the XML objects needed to form the Identity Manager, is not that big, just several 10 MB. On the other hand if your Identity Manager is expected to be high available, the database also must be high available. Simply put, without the repository there is no Identity Manager. Therefore most installations are using cluster technology like Sun Cluster to make the database platform as available as possible.
Concerning the Identity Manager it is questionable if it must be high available at all. All applications continue to work even if the Identity Manager is not available. If on the other hand the Identity Manager forms your user self service, it is a good idea to increase the end user experience and to have this page as available as possible.
The Identity Manager functions like any other web application, therefore a load balancer is used to establish high availability. The load balancer supplies a virtual endpoint for the service and balances user requests to as many Identity Managers as needed. But keep in mind, that all instances of the Identity Manager have to rely on the same repository database.
Security
Identity Manager is using so called Server Encryption Keys to securely store sensitive data in its repository
user passwords
user previous passwords (history)
user answers
resource passwords
user previous passwords (history)
user answers
resource passwords
The Server Encryption Keys are symmetric triple-DES 168 bit keys. There are two types of keys supported by the server. The first is the default key which is compiled into the server code. The second is a randomly generated key that is generated while populating the repository.
The Server Encryption Keys are objects maintained in the repository. The number of encryption keys in a given repository is not limited. Identity Manager is using the current default Server Encryption Key to encrypt each piece of sensitive data to be stored into the repository. The encrypted data is prefixed by the ID of the encryption key that was used to encrypt it. When an object containing encrypted data is read into memory, the encryption key associated with the ID prefix is used on decrypt it.
It is therefore very important that any Server Encryption Key referenced by some object's encrypted data has to be available in the repository; otherwise, the server will not be able to decrypt it.
If an object containing encrypted data is imported from another repository or IDE, then the associated server encryption key must first be imported to ensure the object can be successfully imported.That said, after the deployment of IDM one of the first actions should be to export the server keys and check them into the version control system. If there are multiple developer that might create encrypted data (see above for types), all of them should export the Server Encryption Keys of their environment and check it into the version control system. To avoid these multi-key issues, as well as to maintain a higher level of data integrity, use the Manage Server Encryption Task to re-encrypt all existing encrypted data with the "current" server encryption key. This Task allows an authorized security administrator to do several key management tasks including generate a new "current" server key and/or re-encrypt existing objects, by type, containing encrypted data with the "current" server key. For more you can find the Identity Manager Administration Guide
After re-encrypting everything with a newly created key, feel free to remove all keys but the newly generated one.
To generate XML objects that include encrypted data like Resource Adapter definitions or administrative accounts, I usually use the Identity Manager wizards to create the objects and export them afterwards. Therefore the data is correctly encrypted but tied to the current default Server Encryption Key of the environment the objects are created in.If I don't want to have this dependency I can replace the password attribute with the asciipassword attribute and supply the password in cleartext. Which is obviously not a good idea in a production environment.
Source from Some Sun Website, Some Blogs and some Content created by Tanweer
