- Access Control
- Alternative Hierarchies
- Data Upload
- Directory Information Tree & Directory Schema
- Directory versus Database
- Double Byte Support
- Implementation Guides
- Military & Intelligence
- Organization Charting
- Platforms Supported
- Search Capability
- Standard Support
- Support & Maintenance
- Viewing Content
- What is XED?
- XACML & SAML
- XED (XLDAP) Versus DSML
- XML Applications
YES. ViewDS Directory Server’s Basic Access Controls can enable and disable access on an attribute by attribute basis. The access controls that are configured within ViewDS Directory are enforced for all of the access protocols as well as the Access Presence interface.
YES. All ViewDS Directory screens can be completely tailored to suit individual needs, as well as organization requirements.
YES. ViewDS Directory has a highly flexible pre-processing feature that can restrict fields by: Length, Case, Phone number, to being able to choose from a list of predetermined words.
YES. Keyboard mapping functions can be re-initialized within the system, to accommodate most terminal types.
YES. ViewDS Directory supports a number of different access control models. It supports the X.500 access control model that provides enough flexibility to control access to ViewDS Directory data. This model is used widely by ViewDS Directory users, in some cases simply controlling read versus write access, whilst in others providing fine gained access to classified information. This access control model can make use of user and resource attributes, as well as static user roles. In addition, ViewDS Directory supports XACMLV3.0 which is a policy-based access control model. XACML offers both attribute and role-based access controls and can be used to provide an externalised access control service in addition to protecting the data held within ViewDS Directory.
Alternative hierarchies is a concept more than a technology in its own right. By leveraging data that exists in most organizations, we can derive other ways of looking at the same personnel. Most directory systems will come across the same problem during their design phase. What should the directory hierarchy represent? Some examples are:
- A flat structure – Easy to manage but not very useful when viewed by users.
- A hierarchy based on physical location.
- A hierarchy based on the department people belong to.
- A combination of the previous two: Physical structure for the first level then org structure at each physical location.
The main idea behind alternative hierarchies is to offer a number of different structures from a single set of data. An example of this is a structure as detailed below:
This can also be represented as:
As seen by the project structure, not every entry needs to be included and in some cases there may be several fragmented structure.
YES. ViewDS Directory supports the dynamic retrieval and display of alternative hierarchies.
Whilst the requirements are quite simple in technical terms they can be a little complex to manage. For each structure that you wish to represent, there needs to be an attribute in each entry that stores a reference to the entries superior. It must store only the direct superior as that entry will also store its superior and so forth. While this is easy to store, the management of this data grows exponentially with the number of structures to track. This load is easier to manage with automated tools (external sources of data) or by allowing users to manage their own details.
- Simple Authentication using User Name & Password
- Digest-MD5 Authentication using SASL
- Strong Authentication using X.509
- Anonymous Authentication
- Kerberos V5 (GSSAPI) authentication using SASL
ViewDS Directory supports X.500’s strong authentication and LDAP’s SASL External Bind. In both of these cases, digital certificates are used to establish the identity of the user.
ViewDS Directory provides a number of ways for populating the Directory as follows:
- ViewDS Directory has an integrated web-based Directory User Agent (Access Presence) that can be used to access the ViewDS Directory directory and provide user self service. Access Presence dynamically leverages the access controls within ViewDS Directory, only permitting users to perform the actions that they are entitled to complete.
- ViewDS Directory supports LDIF files (Lightweight Directory Interface Files), allowing data produced from another Directory or Directory aware application to be loaded into ViewDS Directory
- ViewDS Directory supports X.525 replication. This allows ViewDS Directory to receive in real time data from another Directory server supporting X.525.
- ViewDS Directory has integrated synchronization capabilities in it’s Stream DUA (SDUA) command line tool. These allow the content in ViewDS Directory to be synchronized with external directory data.
- For more complex integration and synchronization tasks, ViewDS Directory Identity Bridge provides an additional capability.
NO. ViewDS Directory technology places no limitation on the number of users the system can accommodate. The only limitations reside with the number of users your license supports, and secondly, the number of physical users able to connect to your chosen hardware platform.
NO. There are no inherent size limitations. If necessary however, the ViewDS Directory user interface can be tailored to restrict the size of certain fields.
The size of the database is only restricted by the capacity of the hardware platform being utilized. There are no practical software limitations on the number of entries that may be present within a Directory Information Tree (DIT). By having multiple servers communicating to each other by chaining requests, any practical limitation can be overcome.
A number of our customers use ViewDS Directory daily and maintain large quantities of identity data, in the range of 100,000 to 500,000 entries. Internally, scalability and performance testing are performed with a 150 million entry directory and excellent performance results are achieved.
YES. This can be achieved by either using ViewDS Directory StreamDUA or if the requirements are more complex using ViewDS Directory Identity Bridge.
Third party products can be integrated with ViewDS Directory to provide the ability to dynamically represent information and multiple namespaces.
No. Unlike most other LDAP Directories, this does not require a synchronization and correlation task and can actually be completed very simply with just three clicks using ViewDS Directory Movement of Government changes facility. This facility allows a Directory administrator to move non leaf entries from one branch or location of the Directory to another with just three actions. Full referential integrity is maintained with all directory data moved including references and links. For the Military & Government this is the way that Task Groups or Battle Groups can easily be created, moved or dissolved according to operational tempo requirements or in order to meet ORBAT (Order of Battle) requirements. Similarly re-organizations of Government Agencies or Departments is easily achieved with just three clicks whilst still maintaining all referential links.
YES. ViewDS Directory supports multiple schemas running on the same ViewDS Directory server simultaneously and also supports virtual joining of that data into a common namespace.
YES. ViewDS Directory is one of the very few vendors worldwide to have implemented and support the ACP 133 Edition C and Edition D (Allied Communications Protocol) schemas.
The directory information tree is the hierarchy of entries held in the directory (possibly distributed across many different directory servers). Each entry in the tree typically corresponds to a real world object. Each entry is the “child” of the entry above it in the tree, stretching back to the master “root” entry. The following diagram shows an example where an organization called TelcoCorp has organized the directory information tree by service type (EmailService) and then by subscriber (John Doe).
The directory schema is the collection or rules about what can be held in the directory and the structure of the directory information tree. For example, the schema can define: • the information that can or must be held in each type of directory entry – the schema for directory tree shown in the diagram might specify that user entries have to include an e-mail address • which entries can be placed as “children” of which other entries – the schema for the tree shown might specify that users have to appear “under” an organizational unit The LDAP and X.500 standards define a number of schema rules, which directory servers can choose to support and police. The broader the checking, the more directory clients can depend on the information in the directory to be well formatted. There are a number of standard directory schemas that have been defined to simplify the interoperability of directory clients and servers, such as the inetOrgPerson schema for users.
Within ViewDS Directory, there is no inherent restriction upon the types of information that can be stored in the database. Data can be text, binary, video, sound, picture formats (such as GIF) – it can be as flexible as your organization requires.
NO. The ViewDS Directory system has its own database system, written specifically for ViewDS Directory, which has been tuned for optimal performance.
YES. ViewDS Directory encompasses a “Global Changes” facility that allows a user to make changes to fields in the whole of the Database, or a portion thereof.
YES. ViewDS Directory allows users with the correct permission (such as database administrators) to move or rename whole branches of the directory hierarchy. This is particularly useful for corporate reorganizations or name changes.
YES. Directory backup can be performed without needing to stop the Directory Service Agent (DSA).
YES. ViewDS Directory customers report excellent stability and reliable database performance. ViewDS Directory’ database was purpose developed as an X.500 compatible database, thus avoiding the inherent problems of using a relational database with an X.500 wrapper (such as the need to map all attributes, and a multi-level client/server architecture).
There are some important differences between directories and relational databases. Directories make the design assumption that the data they hold will be read much more often than it is changed (just as a paper telephone directory is used much more often than it is reprinted). As a result, they incorporate indexing technology that is highly optimized for read and search performance. In comparison to relational databases, directories offer fine-grained flexibility over where particular data is held around a network, and who has rights to administer it. Distributed operation is a design requirement for directories. The protocols used to access directories, usually LDAP, provide deliberately limited facilities. For example, there is currently no standard for “transactions” to maintain integrity between directory entries, nor operations to manage large unstructured binary data. Directories are not intended as a general-purpose replacement for RDBMS or file systems. Inevitably, these differences are blurred in reality, usually for reasons of legacy migration – with some directory-focused technologies being used to provide more general database features, and with relational databases used to store hierarchical data. Where a product requires both directory and relational database views of its data, the most powerful option is to have both and synchronize between them using a smart connector.
On most commercial directory products when an entry is being updated access to that record is normally blocked, unlike a Database where update and read operations frequently occur simultaneously. However, unlike standard LDAP Directories, ViewDS Directory does support this “database” feature, as well as a range of other features such as the ability to do online maintenance without the need to take the Directory off-line.
YES. ViewDS Directory provides support for double byte entries. ViewDS Directory Advanced Search is capable of undertaking searching on all non pictogram/glyph alphabets. Product implementations are already in place for English, as well as Mandarin Chinese (Pinyin and Traditional characters).
Comprehensive documentation is available for implementing and operating the Directory.
ViewDS Directory can be used in:
- Tactical Messaging
- Defence white & yellow pages and as repository for defence role based access control
- Defence Tactical deployment
- Defence JC3IEDM XML Knowledge Repository
- Hub Coalition Border Directory
- Proxy Directory Guard
- Public Key Infrastructure (PKI) and Trusted Third Party deployments
YES. The The Access Presence interface can display information about the actual hierarchy of information and alternative hierarchies in “real time”.
Alternative hierarchies are those which exist through linkages between entries (e.g. a “Reports To” link which refers to a person’s manager). The user interface can be used to display hierarchical data in a number of formats . Such formats can vary from simply informational text based displays to graphical organizational charts.
Up to 90% of ViewDS Directory searches will be returned to the user within one (1) second. This is dependent upon factors such as the structure of the database, Query Optimization format, size of the database, machine capacity and type, the type of search conducted and the protocol being used.
Normal lists generate output in HTML; XML reports generate output in XML which can then use XSLT for display on web pages or DSMLv1 or DSMLv2 for data dumps. PDF list reports output reports in PDF format. Reports can also be customised on demand for instance producing lists of First Aid officers where their certificate of currency is still valid at a certain date.
The ViewDS Directory DSA server will run on Intel platforms and any platform supporting RedHat Linux such as IBM Linux Servers.
The ViewDS Directory software encompasses the server, the VMA Windows-based management application, and the Access Presence web-based user interface. The ViewDS Directory server runs on Windows Server 2003 or above, RedHat Enterprise Linux 5 or above, and Solaris 10 or above.
YES. The reporting subsystem can request reports by organizational sub-tree, and on certain criteria contained within each record. Such reports as Facsimile or mobile phone directories can be produced with ease.
YES. ViewDS Directory provides a highly flexible report generator system that can provide directory listings and reports through the user interface, or directly from the command prompt.
YES. ViewDS Directory offers a facility to produce billing information on-line, based upon usage.
YES. The ViewDS Directory solution comes with a lightweight report generation tool called the PrintDUA (or PDUA for short). The PDUA allows you to define specific reports that can be executed at any time. The report generation process can be instigated from Access Presence and will produce reports that reflect the current information within the ViewDS Directory server. Dynamic report generation solutions have been delivered in a variety of customer solutions. Such reporting solutions allow users to dynamically define the reporting criteria through a web interface and produce instantaneous reports.
YES. ViewDS Directory provides support for approximate matching on a search request, including phonetic matching and spelling correction, truncation matching, abbreviations, keyword matching, synonyms, and combinations of these.
Powerful Approximate Matching
- Human users won’t always be precise in searching a directory
- Names can be mis-heard, transcribed incorrectly or shortened.
- A user may not be familiar with the conventional function or service keywords
- An acronym or abbreviation could have been used rather than the full title
- ViewDS Directory supports a range of approximate matching strategies to better support searches by human users
- fuzzy logic used to rank and return the best results
- specialized indexes for rapid evaluation of approximate matches on large databases
Approximate Matching Strategies
- Phonetic matching e.g. “pane” will match “payne”
- Typing correction e.g. compensates for missing and transposed characters
- Stem matching e.g. “optics” will match “optical”
- Synonym matching e.g. “Bob” will match “Robert”, “road” will match “street”
- Abbreviation matching e.g. “NSW” will match “New South Wales”
- Word matching, including word synonyms, word phonetic matching and word typing correction
YES. ViewDS Directory supports the Virtual List View extension for the Lightweight Directory Access Protocol (LDAP) Search operation (from Version 7.1 onwards). This extension is designed to allow the “virtual list box” feature, common in existing commercial e-mail address book applications, to be supported efficiently by LDAP servers. The extension allows a client to specify that the server return, for a given LDAP search with associated sort keys, a contiguous subset of the search result set. This subset is specified in terms of offsets into the ordered list, or in terms of a greater than or equal comparison value.
ViewDS Directory supports the following security policies and standards:
- Password Protection LDAP Password Policy Password Hashing in storage and transit (MD5 and SHA1)
- Strong Authentication RFC 4422 – SASL EXTERNAL for PKI based LDAP Authentication Strong Authentication through X.509. (Users and other DSA’s)
- Communications Security LDAP over SSL SSLv2 SSLv3 TLSv1
- Directory Proxy Security
- XACML V3 To provide a policy-based approach for controlling access to ViewDS Directory data and an authorization service for applications.
YES. ViewDS Directory supports DAP and LDAP v2 & v3 interfaces. ViewDS Directory also supports the XLDAP interface defined within the XED standards.
YES. A specialist team of development, maintenance and support staff has been created to guide the development of ViewDS Directory. This team includes staff, who have a thorough knowledge of both the product architecture and all relevant standards (X.500, LDAP and XED). These staff actively contribute to several ITU-T and IETF standards on Directory related topics.
YES. ViewDS Directory supports ACP 133 Editions C and D.
ACP 133 Ed D is the Allied standard for military directories: “Common Directory Services and Procedures”. Allied Communication Publication (ACP) 133, defines the Directory services, architecture(s), protocols, schema, policies, and procedures to support Allied communications, including Military Message Handling System (MMHS) services based on ACP 123, in both the strategic and tactical environments. among the Allied Directory domains and within a domain for combined operations. It defines a common Directory schema which shall be supported by all Allies for international and combined operations. It offers support for Internet mail users and transitional support for ACP 127/Joint Army, Navy, Air Force Procedure (JANAP) 128. The Directory has the potential to support different views of directory information such as white pages and yellow pages services. ACP133 Ed D directory services are based on the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) X.500 Series of Recommendations and the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) 9594.
The ACP 133 directory is designed as general purpose infrastructure used by Defence & Intelligence communities that can hold information for a range of purposes, on roles, end users, organizations and other object. It also identifies security mechanisms that meet the security requirements for strong authentication, confidentiality, integrity, availability, and privilege/label management. Specific functions for which this directory technology is intended and widely used are:
- Support of ACP 123 and STANAG 4406 Military Messaging.
- Support of (legacy) ACP 127 Military Messaging.
- Support of user identification for authentication purposes.
- Storage of X.509 PKI information.
- Support for other applications, and for operation of tactical, mobile and deployed directories.
- A general purpose information lookup (white pages or yellow pages) service.
- Support for National Border Directories
YES. ViewDS Directory from v7.1 onwards provides full support for SPMLv2 (DSML profile) where ViewDS Directory is consuming SPML from other Identity Management applications provisioning data into ViewDS Directory.
YES. ViewDS Directory from v7.1 onwards supports the output of identity data in both DSMLv1 and DSMLv2 format.
YES. Our global support centre provides support and maintenance to customers and partners in 20+ countries.
ViewDS Directory can be accessed by any LDAP or DAP enabled application as well as LDAP libraries supported by scripting (E.g. php, perl and VBScript) or development (e.g. Java, .NET) language. ViewDS Directory provides web based access through a ViewDS Directory module known as ViewDS Directory Access Presence. This is a Web based Directory User Agent; command line access through the SDUA; printing and report access through the PDUA.
Access Presence (previously called the WebDUA) is a web base user interface that provides an out-of-the-box web interface for ViewDS Directory, which cuts the cost of implementation of Directory solutions. It comprises a set of templates that can be customised to fit practically any web environment. But its real strength is its use of parameterised schema to control the directory content and to some extent its presentation. Search forms, attribute and object class presentation and alternate hierarchy relationships are all configured through the ViewDS Directory schema. This task is made simple through the ViewDS Directory Management Agent. ViewDS Directory Access Presence of course also leverages the ViewDS Directory approximate and component matching capabilities to deliver highly sophisticated and world leading search capabilities. The end result is platform for the rapid development easy maintenance of any number of directory applications including:
- White and Yellow Pages
- Self-service portals
- Organisation charting
- Identity store
- Alternative hierarchy management
- Certificate management
- Position and delegation management
The XML Enabled Directory (XED) framework leverages existing Lightweight Directory Access Protocol (LDAP) and X.500 directory technology to create a directory service that stores, manages and transmits Extensible Markup Language (XML) format data, while maintaining interoperability with LDAP clients, any LDAP enabled application, X.500 Directory User Agents (DUAs), and X.500 Directory System Agents (DSAs).
- semantically equivalent XML renditions of existing directory protocols,
- XML renditions of directory data.
- the ability to accept at run time, user defined attribute syntaxes specified in a variety of XML schema languages.
- the ability to perform filter matching on the parts of XML format attribute values,
- the flexibility for implementers to develop XED clients using their favored XML schema language.
The XML Enabled Directory allows directory entries to contain XML formatted data as attribute values. Furthermore, the attribute syntax can be specified in any one of a variety of XML schema languages that the directory understands. The directory server is then able to perform data validation and semantically meaningful matching of XML documents, or their parts, on behalf of client applications, making the implementation of XML-based applications easier and faster. XML applications can also exploit the directory’s traditional capabilities of cross-application data sharing, data distribution, data replication, user authentication and user access control, further lowering the cost of building new XML applications.
The eXtensible Access Control Markup Language (XACML) is an XML dialect for the server-side representation of access control policy and access control decisions. These rules can be expressed in an application-independent manner, making it versatile. XACML polices can reference other policies, and can intelligently combine policies with competing or overlapping rule sets. If the provided combination algorithms are not sufficient, application developers can define their own as needed. XACML can be used to implement Attribute Based Access Control (ABAC). Traditional access control methods such as Identity Based Access Control (IBAC), or the newer Role Based Access Control (RBAC), associate access permissions directly with a subject identity, or with the role that subject is attempting to perform. IBAC, in which an access policy needs to be defined for every identity, is a method which does not scale well and is repetitive and redundant. RBAC requires that access policies be defined for all roles in the system,and then subject identities are mapped to those roles. This scales better,but still has limitations from this one-dimensional view. RBAC generally requires a centralized management of the user-to-role and permission-to-role assignments, which is not well suited to a highly distributed environment, or to an environment with subjects and resources belonging to different security domains. ABAC is a newer method in which policy rules are defined on attributes of subjects (users, applications, processes, etc.), resources (web service,data, etc.), and environment (time, threat level, security classification,etc.). This allows for a much finer-grained access control policy than what can be achieved with RBAC. Of particular note is the ability to use security classification labels to create rules, allowing for XACML policies to be used in conjunction with the needs for a secure operating system’s Mandatory Access Control (MAC) system. ViewDS Directory supports the X.500 Basic and Simplified Access Control schemes, which offer fine grained authorization controls that generally apply to identities directly or groups of identities. ViewDS Directory provides extensions to the fine grained X.500 access control models to allow uses to be identified through Roles, or more generally through any Attribute associated with identities. Through ViewDS Directory’s support for XML, XACML policies can be stored, validated and indexed within a ViewDS Directory server. This allows ViewDS Directory to be used as a Policy Administration Point (PAP) and Policy Information Point (PIP) by XACML Policy Decision Point (PDP) software.
The complement to XACML for client-side access control is the Security Assertion Markup Language (SAML). This XML dialect is used by the requestor of policy decisions to assert an identity and request permission to access resources. The server handling the request consults a XACML policy to render a decision, which is returned as a SAML response. SAML can be used in some environments to achieve a SSO capability, where users only need to authenticate themselves once. SSO is a “ticketgranting” authentication mechanism, whereby a requestor is supplied with a token that proves that it has successfully authenticated to an identity server “at a particular time via a particular authentication method.” Other servers in the system may accept this token without requiring additional authentication, which simplifies the user authentication process. ViewDS Directory when combined with a Federation server such as PingFederate can act as an Identity Provider (IDP) in an organization’s federation solution.
In our view DSML is half a solution. It provides an XML encoding for LDAP operations, but still assumes that directory attribute values are in the LDAP string format. If you try putting XML in directory attribute values it has to be escaped before it can be transported in DSML. Even worse, DSML represents LDAP extended operations and controls as the base 64 encoding of the octets of the BER encoding of the operation or control, which is practically indecipherable to a human reader. The XED alternative to DSML is XLDAP (a 100% XML version of the LDAP protocol). XLDAP represents XML in directory attribute values natively as XML without escaping. It also provides an XML markup for values of existing complex syntaxes like directory schema definitions (attribute type definitions, object class definitions, etc). LDAP controls and extended operations are also represented as XML markup, never as base 64 or BER. The XED framework allows directory attributes to be created with syntaxes defined in XML Schema, or with a DTD. The directory then understands the structure of the data and can do semantically driven verification and matching of the data. For example, the directory knows that “true” and “1” are equal values for the XSD boolean datatype, and knows how to order values of the XSD dateTime datatype with time zones. Component matching can also be invoked to match specific elements or XML attributes in directory attribute values. The best one can do with DSML is substring matching on the XML syntax, which is a bit hit and miss. Because XLDAP is algorithmically derived from the underlying ASN.1 definitions of LDAP and X.500, every extension to LDAP automatically gains an XML representation in XLDAP. On the other hand, DSML is entirely hand crafted.
ViewDS Directory can basically support any application that creates XML schema and objects and has a need to store the information in a hierarchical data store and to provide sophisticated search and retrieval on that information.
ViewDS Directory has been deployed in conjunction with the IBM Workplace Forms Viewer and Server. This application creates and deploys native XML Forms which can then be stored in the ViewDS Directory Directory under a Person’s entry. In the user case , Personnel records such as Training Evaluation records and Skills Matrix Forms were created for a customer using IBM workplace Forms Server and then stored in the directory. As IBM Workplace Forms support digital signing with X.509 certificates, ViewDS Directory was able to utilize this to provide strong authentication for Access control and using its sophisticated searching capabilities provides for high speed retrieval based on a variety of search criteria. In another case, ViewDS Directory has been deployed in conjunction with the BMC Identity Management Directory Visualization server to do a real time join of information from multiple data sources including ViewDS Directory and utilizing ViewDS Directory’ component search and support for role base access.
XACML, which is the eXtensible Access Control Markup Language, provides an XML based framework for describing access control policies and a processing model. There are a number of elements within the processing model, including a PIP (Policy Information Point) and a PAP (Policy Administration Point). The PIP is a repository, and management interface, for information concerning the users and resources that are the subject of XACML policies. ViewDS Directory is a suitably secure technology that can fulfill the role of a PIP. The PAP is a repository, and management interface, for XACML policies. The ViewDS Directory server, through its support for XML, allows the efficient storage, retrieval and indexing of XACML security policies. Customization of the WebDUA user interface can allow XACML policies, to be defined and managed. Since XACML is a very generic and flexible policy framework, the PAP administration interface is often tailored to meet specific deployment needs. As a combined PIP/PAP, ViewDS Directory offers XACML based environments with a centralized identity and policy store. Centralizing the storage of information provides organizations with an environment that is easier to manage, maintain and audit. Through ViewDS Directory’s XML searching capabilities, components within an organization that are making policy decisions can use ViewDS Directory to quickly locate policy and user information of interest. Future enhancements to the ViewDS Directory product suite will include:
- Enhancements to the PIP and PAP modules and interfaces
- Ability to make policy decisions (i.e. a PDP – Policy Decision Point)
- Ability to utilize XACML for internal authorization decisions
- Ability to offer third party application plug-ins to enforce policy decisions on third party applications.
The operational attributes defined for ViewDS Directory (v6.0-XED) allow XML Schema to be imported into the directory. Once the directory is aware of an XML Schema, the schema definition can be used as the syntax of new user attributes. This allows XML to be stored within the directory, whereby the directory has complete knowledge of the syntax of the XML, which allows it to complete proper XML validation. This provides the directory with the unique capability of being able to accept new syntax definitions from users. This is something that is not possible with current LDAP and X.500 directories. Since the directory has knowledge of the XML Schema, it can complete component matching queries on the XML values. This allows users to construct search operations that interrogate the inner contents of the XML values. This ability transforms a directory from uselessly storing XML BLOBs to intelligently storing and processing XML documents.
ViewDS Directory provides support for the following XML protocols:
- XLDAP (XML Lightweight Directory Access Protocol)
- eBXML Registry Services
- XDAP (XML Directory Access Protocol)
- XDSP (XML Directory System Protocol)
- SPMLv2 – Service Provisioning Markup Language (SPML) is an XML based framework for exchanging user, resource and service provisioning information.
- DSMLv1 & DSMLv2 – Directory Service Markup Language (DSML) is a representation of directory services information in an XML syntax.
Yes, XSL-FO is a language for formatting XML data for output to screen, paper or other media and a number of ViewDS Directory customers use this capability for producing Organization Charts, printed reports and other output media.