[+] All  

The ViewDS Directory Server provides organisations with a fast, scalable and flexible directory system. It has been developed strictly adhering to open standards and features support for the X.500, LDAP, XLDAP and ACP133 Standards. Being standards compliant, ViewDS will interface with a variety of applications.

The public, government and business need for rapid and accurate searching for information is widespread and growing quickly. Information accuracy, availability and accessibility are the factors that allow communication and interaction between people, business and government.

Directories are increasingly being used for this purpose, and there are many suppliers of these - particularly those using the LDAP standards. However often these directories (and relational databases) do not provide functions or facilities that are necessary for a particular application, resulting in poor performance and user dissatisfaction.

In general, directory solutions available in the market provide Soundex search. However this is only a single method of searching for a particular search field and ViewDS offers any number of approximate search methods and combines the results to produce a concise list of responses. This makes ViewDS unique in its ability to produce high quality search results and it facilitates a far richer and satisfying user experience when searching for information when compared to other directory technologies. The choice of which search methods to apply to each searchable attribute or combinations of attributes in ViewDS is completely configurable and specified in the directory schema.

ViewDS Directory server is not just another LDAP directory as it provides:
• World leading approximate matching, making information retrieval highly flexible and user friendly,
• Component matching which enables fine granularity searching
• An integrated Web-based configurable User Interface
• Deep “tree” structures that reflect real organizations. This enables ‘point and click’ “Machinery-of-Government” or organizational structure changes, whilst retaining referential integrity
• Powerful extended Access Control capabilities
• Online Organization Charting, Alternate Hierarchies and Selective Reporting
• Unparalleled syntax support (“intelligent storage”) – over twice the nearest alternative
• Extensible syntax support through XML Schema
• High integrity replication across multiple servers.
• Native support for XML including component match search of detail content

In summary, ViewDS isn't simply a network application used to hold user credentials, nor is it a relational database with an LDAP front end It is a purpose built directory server with a comprehensive list of features developed specifically for that task. Download Whitepaper

The ViewDS Brochure

Industry Standards page

back to top

A searchable registry, or discovery service, is an essential part of many XML-based applications. For example, the Registry Services of ebXML, the Discovery Services of the Electronic Product Code Information Services (EPCIS), the Internet Registry Information Service (IRIS), the XACML Policy Information Point and Policy Administration Point , the Global Justices Data Exchange Model Registry (GJDXML) and Universal Description, Discovery and Integration (UDDI) when used as a discovery service for Web Services. One thing that these independently developed registry and discovery services have in common is that they are application-specific.
That is, the format for records in each registry and the protocol operations (sometimes called interfaces) for creating, destroying, modifying and searching the records in the registry are designed specifically with regard to, and only with regard to, the real-world objects of interest to that application.

However, there is considerable overlap in terms of the real-world objects described by the records in each registry. For example, records containing information about organizations and their staff are common among discovery services. Since each registry uses different record formats and operations an organization deploying two or more of these applications would find itself having to administer duplicate information through differing means.

While some of the application-specific discovery services are claimed to be extensible, extensions to the service can only be effected through additional software development. To support new record formats for additional kinds of real-world objects, or additional properties for existing records, it is necessary to extend the existing standardized protocol operations or implement new protocol operations to add, delete, modify and search the new records or properties (we might call this compile-time extensibility, as opposed to run-time extensibility). Rather than being just application-specific, with such extensions a discovery service becomes vendor or customer specific, to the detriment of interoperability with other implementations of the "same" discovery service.

To greater and lesser degrees, each discovery service specification and/or discovery service implementation has to address a common set of database functions: persistent storage and retrieval, atomic updates, query evaluation, query optimization (e.g. indexing), transactional recovery, transactional consistency, data distribution, replication, authentication and authorization (access controls). So not only is there duplication in terms of the information held across the different registries, but there is also duplication of effort with regard to understanding, specifying and implementing these different registries.

Overall, the various application-specific discovery services are trying to do much the same thing with much the same data about the same real world objects, but are inventing different, incompatible ways to represent and administer that data.

ViewDS provides for XML-based Applications to specify and implement a general purpose discovery server with no built-in preconceptions about the real-world objects, and the properties thereof, that need to be registered and subsequently discovered. This allows a single service to satisfy the registration and discovery requirements of a large range of applications and purposes. Data that is common to those applications is stored once by the service and is administered in one place.

This architecture can be represented diagrammatically as follows.

How the Architecture is Today

 

How the Architecture is With ViewDS

Essential parts of ViewDS are:
1) A flexible general framework in which to describe the record format for representing objects of interest to a registry and the formats of properties of those objects, i.e. the schema for a registry. The properties are possibly complex structured data. Since different registries can involve the same real-world objects it is expected that some parts of schema will be shared by several registries, as will the data itself.

2) The ability to configure the server at run-time with the schema for one or more registries and to extend the schema for an existing registry. With knowledge of the schema for a registry, the server will be able to enforce the correct format for registrations and preserve any consistency and integrity constraints on the registry data.

3) A set of generic protocol operations to create, destroy, modify and search the records of any registry managed by the server. So for example, instead of a separate operation to create a record for each kind of real-world object there is one create operation that takes the kind of object as a parameter (along with the set of properties relevant to an object of that kind as described by the schema for the registry). The search operation will give the users the capability to search on any part or parts of structured properties.

ViewDS, by providing a general purpose discovery service, circumvents the creation of yet more application-specific discovery services (with all the needless duplication and reinvention that entails), and in time, to replace the existing application-specific discovery services. In the meantime the interfaces of these application-specific discovery services can be supported through simple translation layers on top of ViewDS. A translation layer converts data between the application-specific formats and the more general formats used by ViewDS and converts the application-specific protocol operations into the generic operations of ViewDS.

back to top

The Management Agent is a .NET based Administrative Directory User Agent. It is capable of managing multiple ViewDS servers and provides a design, configuration and administration tool for the schema, directory information tool, data attributes, XML schema and XACML policies.

The Management Agent provides three key capabilities:

An Admin Agent to enable :
* Design of DIT
* Design of GUI
* Schema Design and Configuration
* Search Configuration
* Access Control
* Security
* Authentication
* Other components

A Management Agent to configure:
* Multiple Hubs
* Replication Policy
* Federation
* Certificates

An operational Agent to operate all components and to provide access to all logging and auditing data.

back to top

The ViewDS Access Sentinel is currently being developed, leveraging the core underlying ViewDS Discovery Service. It offers a comprehensive solution for Fine Grained Access control by providing the ability to store and enforce XACMLv3.0 compliant policies and profiles. A variety of access control models, including attribute based access controls will be provided by ViewDS Access Sentinel. ViewDS Access Sentinel will offer a combined PAP (Policy Administration Point), PDP (Policy Decision Point), PEP (Policy Enforcement Point), PIP (Policy Information Point), SAML2.0 Identity Provider and an LDAPv3 Identity Store. Other capabilities include Role, Time and Attribute based access control, Policy Guards, Policy Synchronization , Policy Replication (for use in distributed environments such as in Defence) and an API Toolkit capability.

ViewDS Access Sentinel is pictured diagrammatically below:

View demonstration of ViewDS XACML Policy Administration Point (PAP) application template

ViewDS XACML Policy Server

back to top

ViewDS Synchronisation and Integration Smart Connector provides synchronization of delta changes of data (e.g. identity and policy data) from LDAP Directories (such as Lotus Notes, Active Directory and ViewDS), LDIFs (Lightweight Directory Interface Files) to LDAP Directory servers. In general the Connector is deployed with ViewDS to either receive or send data to and from ViewDS. However it can also be deployed as a stand alone connector linking two LDAP Directories. It allows customers to do 'moves' and 'renames' based on 'key' information other than the distinguished name 'dn'. Almost all other synchronization products in the market today have difficulties undertaking this and have to rely on deleting and re-adding entries for moves. This process is acceptable if all the data in 'moved' directory entries is synchronized from external authoritative sources but is a major roadblock if both external information and master additional information needs to be synchronized. In this case data is lost with the move/rename. ViewDS Synchronization & Integration Smart Connector overcomes this restriction and moves and renames can be achieved without data loss. The Smart Connector can also be used in conjunction with third party synchronization tools such as Radiant Logic Radiant One, Microsoft Identity Integration Server, Oracle Virtual Directory, Novell Nsure and IBM Directory Integrator (as these products can all produce the required LDIF input) or, with some scripting, can accomplish simple LDAP synchronization and normalization tasks.

back to top