|
|
|
|
home >
support > frequently asked questions |
 |
|
 |
|
|
RadiantOne fully has been designed and supports a close integration with J2EE.
Many integration points are provided for blending and maximizing the synergy between the two environments. A full description will exceed the scope of this answer but the following two aspects deserve a detailed explanation here: Integration and Security.
Integration
Support of EJBs and web services at the virtualization layer.
There are essentially two ways for VDS to work with Websphere.
a) Calling an EJB from a virtual entry.
Any virtual entry (representing for example a database record or a real directory entry exposed through virtualization) can be associated with a set "Interception Script". These user defined methods for virtual entries (equivalent to stored procedures/trigger mechanisms in a database) are coded in Java and provide access to any Java classes /libraries for further customization. On authentication, search, add, delete, and modify these scripts can override or extend the behavior of a virtual entry. Any EJB (session, entity or message-driven bean) can be invoked from a virtual entry. Moreover to facilitate and optimize the functionality/hosting capabilities of the WebSphere's EJB container, Radiant Logic provides a "session bean facade" template to access any EJB session bean (with its specific business logic hosted by Websphere) while minimizing network remote calls.
b) Virtualizing an EJB object or a Web Service.
Besides databases and directories, RadiantOne can virtualize EJB objects (session, entity or message driven beans) and Web Services supported by Websphere. VDS provides an Interface and a customizable object schema that an EJB or a Web Service needs to support in order to be exposed as a virtual entry. This "implementation" (or "wrapping") is greatly facilitated by helper libraries (parameters, connection, context info) and template provided by Radiant. Essentially, an object should implement some of the methods already described (Search, Add, Delete, Modify). An additional method Invoke allows further customization /calling of any other specific method.
Integration of Synchronization Services with WebSphere and WebSphere Integration Server
RadiantOne provides a set of synchronization services when metadirectory type functionality is needed. RadiantOne connectors are based on JMS and fully leverage WebSphere message queuing capabilities (based on MQ series). Moreover, synchronization messages are XML-based and the connectors can easily interface with WebSphere Integration Server for more advanced workflow and exchange with the WebSphere environment. The Unified Identity Manager process built on VDS synchronization services can participate in complex workflow to build an enterprise-level provisioning infrastructure.
Security: RadiantOne provides full support for the J2EE Security Framework
A secure transaction in J2EE generally involves the following operations:
- Identification (finding a user or "subject/principal" in some common users registry /directory),
- Authentication (verifying his credentials)
- Authorization (enabling access to resources based on roles and permissions defined by policies).
At each step VDS can participate and simplify the process.
Identification: As a standard LDAP V3, out of the box, the Websphere administrative/security console can assign users and groups (static or dynamic leveraging virtual attributes resulting from joins) exposed by VDS to JSP and EJB?s roles and policies.
Authentication and authorization: with VDS, these two operations can be adapted and extended with a lot more flexibility in complex and heterogeneous environments.
Back to Top
|
|
At run-time, the main code for the VDS is about 4 MB on disk. With the different Java libraries and utilities a rough estimate of the working set before any data allocation is around 12-15 MB. This number does not include the footprint of the JVM environment itself. In terms of memory occupation the VDS cache -configurable- represents the major part.
The server is fully multi-threaded and scales fully linearly up to 4 to 6 processors. After that, scalability continues but not fully linearly. The VDS doesn?t have a back-end per se when the persistent cache function is not enabled. If the persistent cache is turned on then VDS provides its own full LDAP back-end (Tests have been done with cache supporting more than 100 millions entries per back-end). Optionally, the back-end used for persistence and write through cache could be any high performance LDAP V3 server.
Back to Top
|
|
In a high availability environment, a first level of failover and load balancing can be established by replicating the same logical image of the VDS across two (or more) servers. A set of hardware load balancers (Cisco, F5) can distribute the load or fail over to a set of redundant VDS server configurations.
Each VDS configuration itself can represent a very complex directory tree with potentially many branches and nodes coming from many different data sources with different latencies. The query load can be very high on some specific part of the tree (authentication hot spots for example) and the underlying data sources could have high latencies. Different strategies can be adapted to provide a high level of availability. Two mechanisms can be leveraged to maximize throughput: smart routing and caching.
Smart Routing: Leveraging the Virtual DIT and RadiantOne LDAP Access Router
One of the strengths of a virtual directory resides in its ability to manipulate the namespace. Dividing an existing tree with new logical branches and then routing the calls directly to these branches can increase dramatically the throughput. Another case is to mount existing directories under a new virtual aggregate tree and then routing to the right suffix. For better scalability and simpler deployment, RadiantOne ships a separate and specialized component (a very small foot print less than 200KB and higher throughput instead of a full fledge virtual directory server only for the purpose of routing) which operates at the level of LDAP packets. The following picture is an example of routing configuration in a real life use case where the calls are dispatched between a (physical) enterprise directory (and fail over) and an e-commerce directory federated under a logical tree.
Caching to increase throughput
A logical tree and routing add flexibility and contribute to increased availability. However, in many cases a solution to high volume and high latency requires caching. This is especially true if there are a high volume of authentication and authorization requests.
Back to Top
|
|
VDS supports many different ways to interface to its environment.
Interception scripts:
RadiantOne VDS supports interception scripts. These user defined methods for virtual entries (equivalent to stored procedures/triggers mechanisms in a database) are coded in Java and provides access to any Java classes /libraries for further customization. On authentication, search, add, delete, and modify operations, these scripts can override or extend the behavior of a virtual entry.
Scriptable data transformation in Synchronization Services:
To synchronize objects in different data sources RadiantOne provides connectors supported by JMS and default synchronization templates triggered on publish/subscribe events. These data transformations are fully scriptable in Java and can access any Java classes /libraries, EJB etc?
Universal Connector Template:
Beside directories, databases and JCA Connectors, specific application connectors can be developed in Java based on a Universal Connector Template that is provided.
Virtualization of EJB's and Web Services:
The Virtual Directory Server provides an interface and a customizable object schema that an EJB or a Web Service can implement in order to be exposed as a virtual entry. This implementation (or "wrapping") is greatly facilitated by helper libraries (parameters, connection, context info) and templates provided in RadiantOne. Essentially, an object should implement some of the methods already described (Search, Add, Delete, Modify). An additional method named "Invoke" allows further invocation of any method specific to a particular object.
Back to Top
|
|
In terms of authentication, VDS acts as an intermediary between a client and the virtualized data sources. Different methods are supported.
Proxy Authentication, Delegation of Credentials:
In the simplest case, the credentials is a password to check against an existing data source. In this case, the VDS acts as a proxy and routes the request to the relevant application. The authentication is delegated to the underlying application. However, even in this simple case, volume and scalability can sometimes be an issue since this method tends to generate many connections (one for each user bind/authenticate against the underlying identity store).
Direct Authentication by VDS:
Another approach is to have VDS maintain the connection (using VDS connection pooling capability) with the data source and providing the authentication itself (a compare credentials operation requiring only a read on an established connection on the data source instead of a full connection and an authentication).
User Defined Method on Authentication:
The two previous methods are typically generic scenarios. In reality, the authentication process could be a lot more complex. Besides passwords, other authentication methods (certificates, Kerberos, Smartcards, tokens, bio-metrics, multi-factors authentication) could be a lot more involved. To support these cases, VDS provides a scriptable (in Java) user defined authentication method for each class of virtual entries. A template greatly simplifies the development by providing all the logic and parameters received at authentication time. The JAAS (Java Authentication and Authorization Service) or any specific libraries accessible from Java can be invoked (for example Smartcard or biometric API). If a specific digest form of the password (hash function) needs to be applied before comparison with the encrypted password in a specific data source then this can be done in this script.
Back to Top
|
|
VDS supports many different levels of logging. Any operation on the directory is recorded in the change log (this can be enabled or disabled). A VDS connector can be installed to notify any applications of a change event. VDS logs its events using the Log4J format. Many reporting/monitoring tools on the market leverage this format. (one example is Chainsaw: http://logging.apache.org/log4j/docs/chainsaw.html).
Back to Top
|
|
Yes! The real value of a virtual directory resides in its capability to federate distributed, heterogeneous data sources. As a virtual directory, VDS can map objects, attributes and transform values. But VDS can also map and navigate the relationships linking different objects. This is particularly important in the case of many databases and applications where many relationships exist between different entities. In particular, these relationships extend the definition of identities in consideration of specific business contexts. In fact, most of the time an identity representing an individual does not contain all possible attributes at all times. Managing such a "mega" identity would be very difficult (how many facets to record?). It is the participation of this individual in different activities, involving different resources (business contexts) that confer to him some specific attributes characterizing his role.
By allowing a navigation of the different levels of relationships, VDS associates identities with the extended attributes they acquired in specific contexts. These extra attributes in turn are used to enable specific security policies.
Back to Top
|
|
Yes! RadiantOne VDS supports extensive caching capabilities. RadiantOne offers a persistent cache that can survive a VDS system failure. The cache works not only for reads but acts also as a pass-thru write mechanism i.e: a modification of an entry is validated first in the real data source before being added into the cache (and propagated into the cache persistent store). The hierarchical structure of a directory allows for a very granular segmentation of the data. Very specific branches of the directory tree can be designated for caching allowing for the best performance possible.
RadiantOne offers a solution that is highly scalable with a persistent cache, which is in fact a full LDAP V3 server based on the same backend architecture (B*trees index) that standard LDAP directories use. The VDS can support a high level of concurrent reads with reasonable memory requirements.
The cache can be refreshed by two mechanisms:
- Scheduled full snapshots: script using an LDAP search with filter specifying the partition to be refreshed.
- Notifications using a data source connector provided by RadiantOne Synchronization Services (working either by polling differences or based on data sources events: triggers for databases or Change Log listeners for directories)
Solution A works well for small cache (less than 200,000 entries) and has the advantage of simplicity.
Solution B is more scaleable but requires a one-time upload of the cache with all the data (for a low-end Pentium class processor configuration uploading the rule of thumb is about a 1,000,000 entries per hour) and the (automatic) application of on-going deltas recorded by the connectors.
Back to Top
|
|
Objects from the underlying data stores are first converted into a common model (schema) and then linked. The schemas from the underlying sources are extracted via a wizard process from the RadiantOne Schema Manager tool. Three different sources are used in diagram 9.1 below to depict this process.
Diagram 9.1: Schema Extraction Process
After the schemas have been described, different virtual directory information trees can be designed using the RadiantOne Directory View Designer tool. Diagram 9.2 below depicts this process.
Diagram 9.2: Directory View Designer Process
Different methods can be used to link objects from different data sources. Objects can be linked through a static label (equivalent to the notion of an OU) or linked together by some common values/keys (the parent object conditions the descendant object: a child object appears only under a parent if there is a common key value with the parent object).
In the case of a directory, there are two ways objects can be mounted in a virtual directory:
1. Starting from a specific naming context (any DN) or root, a whole sub-tree can be mounted. RadiantOne can reverse engineer the entire underlying DIT of a directory and make it logically appear as part of the virtual directory tree. For a database, the relationships that exist between the different objects can be used to build the virtual directory tree (see Diagram 9.3). For more information on virtualizing databases, please continue reading.
Diagram 9.3: Example of a Federated Namespace Provided by RadiantOne
2. Starting from a specific naming context (any DN) or root, all objects (no matter where they are defined) matching some objectclass attributes can be retrieved and mounted. In the diagram below. All objects belonging to the inetOrgPerson objectclass will be shown below the ou=ED node. All objects belonging to the User objectclass will be shown below the ou=PD node. All objects contained in the People table from the database will be shown below the ou=B2B node (see Diagram 9.4).
Note: The objects/attributes from the database table can be mapped as any objectclass/attributes needed. Continue reading for more information on virtualizing database objects.
Diagram 9.4: Example of a Federated Namespace Provided by RadiantOne
In the case of databases, table definitions are converted into objectclasses.
This mapping process is accomplished using the RadiantOne Schema Manager tool. The three screen shots below depict how the mapping process is accomplished.
You can create explicit relationships-driven hierarchies or flat hierarchies from database objects (as described in diagram 9.3 and 9.4 shown above). To build explicit relationships-driven namespaces, VDS leverages relationships between tables based on primary and foreign keys relationships. These relationships are captured during the schema extraction process and can also be defined manually using the Schema Manager tool if needed.
Back to Top
|
|
|
Yes! Any object in a virtual tree can be joined with another object based on the value of some common attribute or by its address (in the form of a DN). If the objects have a common attribute value, then an "attribute matching" join would be configured in the Directory View Designer tool. A DN (an address) that is a reference to the object can also be used to base the join on ("virtual reference chasing" join). The screen shot below depicts where the join is configured.
Many different joins can be configured for each virtual node. See diagrams 10.1 and 10.2 below as examples.
Diagram 10.1: Example of Attribute Matching Join VIRTUAL REFERENCE CHASING JOIN:
Diagram 10.2: Virtual Reference Chasing Join
The value of a virtual entry can also be transformed by a rule defined in an interception script. Interception scripts (written in Java) can be used to override the default functionality of the virtual directory. This opens up the virtual directory and allows for easily customizing the Authenticate, Select, Insert, Update and Delete operations. A default script template is provided and can be customized with the required logic. The screen shot below depicts where the interception scripts are configured.
Back to Top
|
|
The Unified Identity feature of the RadiantOne Synchronization Services allows you to create a unique list of users from multiple data stores. As long as there is a way to apply logical rules to manipulate the data in each source, then there is a way to link and join the common entries together. Default Dynamic Java scripts will be generated automatically, and can be customized to create matching rules to identify the same user in each source. After all scripts have been customized for each source of user information, the Unified Identity Wizard will execute the scripts, perform the matching rules, and upload the unique list into any JDBC-compliant database table you choose. The reference link back to the original source will also be maintained. From this unique list of objects and the reference link, you can dynamically link and join the information across each data source to create a "super entry" (an entry that contains all attributes about the object).
Diagram 11.1 depicts the high level process using three data sources as an example (an HR database, NT Domain and SunONE Directory).
Note: In this diagram, the database table contains two columns. One named CID (which will store the unique Ids) and one named REFDN (which will store the reference link back to the original data store). These column names can be anything you choose.
Diagram 11.1: The Unified Identity Process
1. List User Objects from Each Source - This step involves using the Schema Manager tool to capture the metadata from each user data store.
2. Create Table for Storing Unique Identities - This database table can be defined using the RadiantOne Synchronization Services Administrator and can be created in any desired database.
3. Scripts Defined to Identify Unique Entries in the User Objects - Java script templates are provided by RadiantOne and can be customized with the logic needed to identify common users.
4. Upload Unique IDs into the Staging Engine and Maintain the Reference Point Back to the Original Sources - The upload wizard contained in RadiantOne Synchronization Services will process the Java scripts and store the unique list of users that it discovers along with a reference link in the database table.
Once the unique list of users has been created, RadiantOne connectors can be put in place to keep the sources synchronized. Whenever there is a new user added into one of the underlying sources, the unique list/references will also be updated. This synchronization process is depicted in Diagram 11.2.
Diagram 11.2: The Synchronization Process
5. Synchronization - if a new user entry is created in any of the three underlying sources, the connectors will publish the change to the staging database table.
Example: Note - This example has been simplified to show the underlying thought process that needs to take place in order to identify common users.
Let's assume that some of the same people are contained in the HR database, NT Domain, and Active Directory. You can identify the same person in each source because of their name. However, in the HR database, the attributes that store the name are FNAME and LNAME. In NT Domain, name is stored in cn, and in the SunONE Directory, name is identified in uid. Therefore, in order to compare the name in all sources, FName and LNAME need to be concatenated together for the HR database, uid in SunONE needs to have the underscore that separates the first and last name removed, and cn from NT Domain can be used just as it is. After this manipulation, all of the values can be compared to find common users. This process is depicted in Diagram 11.3.
Diagram 11.3: Customizing the Logic that will be used to Define Common Users
Now, the information contained in the staging database table (the common IDs and the reference links) can be leveraged by the VDS to solve problems such as:
- Creating joined user entries for unique profiles (for an example see Diagram 10.2 located in FAQ # 10).
- Identifying orphan accounts (accounts that should or should not be in one of the sources).
- Using the result as a beginning architecture for provisioning/de-provisioning.
Back to Top
|
|
Radiant Logic licenses its technology in one of 2 ways:
1. On a per virtualized user basis (how many unique user identities and associated attributes are exposed through the Virtual Directory)
2. On a per server, per CPU basis
Back to Top
|
|
RadiantOne VDS includes three main configuration tools and two directory client tools. The configuration tools are: the Schema Manager, the Directory View Designer, and the Virtual Directory Server Console. The two directory client tools are: the SmartBrowser and the Advanced LDAP Browser.
Schema Manager:
The Schema Manager tool is used to inventory all of the data sources that you want to comprise the virtual directory. The Schema Manager tool will extract the objects and relationships from each data source. After the metadata from each source has been extracted, primary keys and relationships can be declared and objects and attributes can be mapped to LDAP object classes and attributes. This information will be used to build virtual directory trees.
Directory View Designer:
The Directory View Designer tool is used to create directory trees and design the namespace. Multiple different directory trees can be built from the same data source, thereby allowing each application to have their own custom view of the data. The Directory View Designer also allows you to quickly view what the instantiated directory tree will look like. To provide greater flexibility, the Directory View Designer provides script templates to allow directory architects to customize how the VDS will process operations such as authentication, reading, updating, and deleting information. The VDS will process each request using the default functionality unless there is an interception script that dictates what actions should be taken.
Virtual Directory Server Console:
The Virtual Directory Server Console is used for configuring the VDS deployment parameters and the local LDAP storage (if one is needed). Cache settings, indexes, proxy settings, the VDS schema, and ACIs are configured here along with other server parameters such as logging, SSL settings, administrator and port information.
Advanced LDAP Browser:
The Advanced LDAP Browser is an LDAP client that allows for browsing and modifying LDAPv3 compliant directories including virtual directory data. You can generate LDIF files from directory trees and even export data directly into other LDAP v3 directories.
SmartBrowser:
The SmartBrowser is a web client that easily enables browsing through the virtual directory contents or any LDAP v3 enabled directory server. This works with any standard Internet browser (Internet Explorer v5.5 or Netscape Communicator v4.7), and the only part downloaded to the browser is a small java applet. All of the other needed components reside on the server.
Back to Top
|
|
Yes, both options are available. In addition to virtual directory services, RadiantOne also offers a full synchronization services architecture.
Back to Top
|
|
During the configuration of synchronization services, transformation scripts are customized to define how the data should be modified before the message is sent to the destination data store. Script templates are provided in RadiantOne. The transformation scripts will be executed inside the Synchronization Hub. You also have the ability to create Message Driven Beans (MDB) out of the transformation scripts and execute them inside of any J2EE-compliant Application Server (instead of using the Synchronization Hub). Executing the MDB inside of an Application Server provides better performance, security, and transactions. When there is a change in one of the data sources, the connector will be notified, format a message in XML and store it in the JMS message queue. The Synchronization Hub will receive the message, transform the data based on the Dynamic Java scripts, and store it in the message queue. The destination connector will be notified of the change, receive the message and apply the change to the destination. See Diagram 14.1 for a high level architecture.
Diagram 14.1: Synchronization Services Architecture
Back to Top
|
|
- Active Directory
- IBM Tivoli Directory
- Novell eDirectory
- SunONE Java Directory
- Oracle Internet Directory
- Exchange 5.5
- NT Domain
- Lotus Notes
- Oracle
- SQL Server
- Sybase
- UDB (DB2)
- RACF
A universal XML-based Connector SDK is provided for accessing proprietary directory sources
Back to Top
|
|
Any JMS-compliant messaging server such as:
- BEA WebLogic
- IBM WebSphere
- SunONE Message Queue
- SonicMQ
Back to Top
|
|
Configuration is accomplished using the Synchronization Services Administrator tool. The high level steps needed to configure synchronization are as follows:
- Inventory the data sources that you want to synchronize.
- Create a topology (a graphical representation that depicts the objects and the flow of synchronization sources, destinations, etc).
- Edit the Dynamic Java scripts to customize the needed transformation.
- Upload the data into the destination object (this is optional).
- Configure the connectors for each data source (to capture delta changes).
- Start the JMS Server, the Synchronization Hub (or Application Server), and the connectors for each source.
Back to Top
|
|
The Synchronization Hub is a Java-based application that processes the transformation scripts. The Synchronization Hub can be replaced by a J2EE-compliant application server (i.e. BEA WebLogic) to provide better performance, security, and transactional functionality. The transformation scripts can be turned into Message Driven Beans (MDBs) and then executed inside of the application server.
Back to Top
|
|
The transformation scripts are written in Dynamic Java. A script template is provided and can be customized for the needed data sources. RadiantOne Synchronization Services includes a utility to convert the transformation scripts into Message Driven Beans if you want to be able to deploy them inside an application server.
Back to Top
|
|
Yes, the synchronization services can be used to synchronize objects from heterogeneous sources and can be used to send cache refreshes to the VDS when data sources change.
Back to Top
|
|
If the JMS Server is not available, the Hub and the Connectors will store their messages. The messages can be resent with the recovery utility provided in the Synchronization Services.
Back to Top
|
|
If a connector is not available, the JMS Server will store the message (for a configurable period of time) and retransmit the message once the connector is available.
Back to Top
|
|
If the hub is not available, the JMS Server will store the message (for a configurable period of time) and retransmit the message once the hub is available.
Back to Top
|
|
- Windows
- Solaris
- Linux
- AIX
- HP-UX
Back to Top
|
|
No. The connectors can be installed on any machine that has access to both the data source and the JMS server.
Back to Top
|
|
For databases, changes can be detected either by installing triggers on the database table(s) that changes need captured from or using a polling mechanism (the polling interval can be customized).
For directories, changes can be detected either by using a change log (if one is provided and can be enabled on the directory) or using a polling mechanism (the polling interval can be customized).
Back to Top
|
|
Contact information for Radiant Logic, Inc:
E-mail: sales@radiantlogic.com
Phone 415.209.6800
Fax 415.892.7085
Back to Top
|
|
|
