YES. ViewDS's Basic Access Controls can enable and disable access on an attribute by attribute basis. The access controls that are configured within ViewDS are enforced for all of the access protocols as well as the WebDUA web interface.

YES. All ViewDS screens can be completely tailored to suit individual needs, as well as organization requirements.

YES. ViewDS 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 supports a number of different Access Control methods. ViewDS supports the standardized Basic and Simplified Access Control schemes, that allow fine grained access controls to be defined for specific identities, groups of identities, or identities that reside within designated portions of the DIT.

ViewDS 7.0 extends the fine grained access control rules to apply to users dynamically, based on their attributes. This access control scheme allows the identities to which rights are granted/denied with to be specified in an Attribute Based manner. Such attributes may be associated with an identity's role, rank, security clearance or any other attribute that may be held within the identity's entry. This access control model provides all of the benefits and capabilities of RBAC (Role Based Access Control), with the flexibility of being extended to encompass additional information.

Alternate Hierarchies is a concept more than a technology in their 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 Alternate 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, 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. ViewDS fully supports the dynamic retrieval and display of alternate hierarchies.

• Simple Authentication using User Name & Password

• Digest-MD5 Authentication using SASL

• Strong Authentication using X.509

• Anonymous Authentication

ViewDS 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.

NO. ViewDS 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 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.

The largest ViewDS database in daily use has over 200,000 entries, which is used by a large Australian government organization. However, a database of over 32,000,000 entries has been tested with excellent performance results.

ViewDS provides a number of ways for populating the Directory as follows:

a) ViewDS has an integrated web based Directory User Agent (WebDUA) that can be used to access the ViewDS directory and provide user self service . The WebDUA dynamically leverages the access controls within ViewDS, only permitting users to perform the actions that they are entitled to complete.

b) ViewDS supports LDIF files (Lightweight Directory Interface Files), allowing data produced from another Directory or Directory aware application to be loaded into ViewDS

c) ViewDS fully supports X.525 replication. This allows ViewDS to receive in real time data from another Directory server supporting X.525. As an example ViewDS has been deployed by a number of Defence Agencies and used in the coalition Border directory role providing linkage to both the US Defence and UK Ministry of Defence Directory servers with both these being from different suppliers but both using the X.525 replication protocol

d) ViewDS has integrated synchronization capabilities into it’s command line tool called the Stream DUA (SDUA). This allows the content in ViewDS to be synchronized with external directory data. e) For more complex integration and synchronization tasks, third party products such as Radiant Logic's ICS server (Identity Correlation and Synchronization Server).
ICS builds a common identity and provides a global profile out of existing identity sources, providing metadirectory-type functionality with easy integration of disparate data sources and without the strain of costly data replication. Within ICS, data sources are mapped, data is virtualized into a common schema, and correlations between identity profiles are established. Identity data is aggregated into a central hub and synchronized across the enterprise according to customized business logic.

Absolutely. This can be achieved by either using ViewDS StreamDUA or if the requirements are more complex using a third party product such as Radiant Logic’s ICS server (see above).

Third party products such as the Radiant One virtual directory, are integrated with ViewDS 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 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 supports multiple schemas running on the same ViewDS server simultaneously and also supports Virtual join of that data into a common namespace.

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, 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 system comes complete with its own Database system, written specifically for ViewDS, which has been tuned for optimal performance.

YES. ViewDS 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 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 customers report excellent stability and reliable database performance. ViewDS' 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.

Yes ViewDS provides full support for double byte entries.

ViewDS 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) with Arabic under development.

A number of Implementation Guides are available for ViewDS to assist you in implementing ViewDS onto various platforms.

Yes. ViewDS is one of the very few vendors worldwide to have implemented the ACP 133 Edition C and Edition C supplement (Allied Communications Protocol). ViewDS in fact is in use today in both the Australian & Singapore Defence Forces and is also deployed in a number of test bed facilities in NATO and in the United Kingdom. It is also used by Clearswift UK to support its Common Criteria EAL4 Deep Secure & Directory Bastion High Assurance Guard technology and its ACP 145 Gateway environments. In the United States a number of Defence Systems Integrators have integrated ViewDS with their technology and indeed eB2Bcom partners with Commpower a US Defence software company.

ViewDS can be used in:
a) Tactical Messaging
b) Defence white & yellow pages and as repository for defence role based access control
c) Defence Tactical deployment
d) Defence JC3IEDM XML Knowledge Repository
e) Hub Coalition Border Directory
f) Proxy Directory Guard
g) Public Key Infrastructure (PKI) and Trusted Third Party deployments
Please refer to Applications section for more details.

Yes. The ViewDS WebDUA interface can display information about the actual hierarchy of information and alternative hierarchies. Alternative hierarchies are those which exist through linkages between entries (e.g. a “Reports To” link which refers to a person’s manager).

Being a web based service, the WebDUA can be implemented 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 searches will be returned to the user within one (1) second. This is dependant upon the following factors: 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.

The ViewDS DSA server may run on a Sun or Intel platform, plus any platform supporting RedHat Linux such as IBM Linux Servers.

The ViewDS software encompasses the server technology, a Microsoft Windows based management application, and a web based user interface (WebDUA).

YES. ViewDS 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. 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 offers a facility to produce billing information on-line, based upon usage. One Health customer has fully integrated ViewDS using XLDAP into their TELMAX Telephony billing system and their SMILE Attendant Call work station.

Yes. The ViewDS 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 the WebDUA user interface and will produce reports that reflect the current information within the ViewDS 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.

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.

YES. ViewDS 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 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 you can. The steps are:
1. Enable the LDAP port on the ViewDS Server (if not already enabled) note the base entry of the directory, server name and port number. If the server required authentication, then the DN of the login user and password are also required.

2. Open Outlook and go to "Tools"->"Email Accounts...."

3. Select "Add a new Directory or Addressbook"

4. Select "Internet Directory Service (LDAP)"

5. Enter the server name and if a user login is required then enter the user dn and password.

6. Click on "More Settings..."

7. In the "Connection" tab enter a name for the directory and the port number for the ViewDS LDAP port.

8. In the "Search" tab enter the base dn for the ViewDS directory

9. Click "ok" then "Finish" to finalize the connection and return to the outlook window.

10. Now each time you search for a person (either by opening the address book or typing their name into a "To:" field) it will also search the directory for the person.

ViewDS 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
ViewDS has also been tested and deployed in conjunction with the Radiant Logic RadiantOne Virtual Directory Server and the Oracle - Virtual Directory Proxy using LDAP. ViewDS has also been fully tested, and deployed in a number of CWIDs with the Clearswift EAL4 Directory Bastion - High assurance Directory Guard solution using X.525 Replication for Coalition Directory Boundary Agent configurations. Clearswift EAL4 Directory Bastion - High assurance Directory Guard solution using X.525

YES. ViewDS supports DAP and LDAP v2 & v3 interfaces. ViewDS also supports the new XLDAP interface defined within the XED standards. For more information visit the XED website which is listed in the Links section.

YES. A specialist team of development, maintenance and support staff has been created to guide the development of ViewDS. 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 supports ACP 133 Edition C.

ACP 133 Ed C is the NATO Standard for Military Directory: "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 C 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 from v7.1 provides full support for SPMLv2 (DSML profile) where ViewDS is consuming SPML from other Identity Management applications provisioning data into ViewDS such as Radiant Logic Radiant One.

Yes. ViewDS from v7.1 full supports output of identitity data in both DSMLv1 and DSMLv2 format.

YES. An email address is provided to ViewDS customers as a central source of support and maintenance inquiries.

ACP133 – ACP133 defines the Directory services, including schema, policies, and procedures, to support military communications.

AdminDUA – A deprecated component of ViewDS that has historically been used to administer a ViewDS server. This component has been replaced by the ViewDS Management Agent.

DAP - The Directory Access Protocol is used for communication between an X.500 DUA and an X.500 directory server.

DISP - The Directory Information Shadowing Protocol is the standardized replication protocol used by X.500 directory servers.

DSA – The Directory System Agent is a server in a distributed directory system which holds some part of the directory information.

DSP - The Directory System Protocol is used for communication between X.500 directory servers providing a distributed directory service.

DSML - The Directory Services Markup Language V2.0 provides a method for expressing LDAP queries and updates (and the results of these operations) as XML documents. The directory data is however still represented in the usual LDAP formats.

DUA – The Directory User Agent sends query and update requests to directory servers on behalf of users, and presents the results of those requests.

ELDIF – ELDIF extends the LDIF specification to allow XML information within a directory to be represented in a human readable format, instead of BASE64. This allows people to clearly read and manipulate any XML information, with out the requirement of decoding it first.

IDM - The Internet Directly Mapped protocol (a.k.a. IDMP) is a mapping of the X.500 protocols directly onto TCP/IP, by-passing and removing the need for the OSI protocol stack.

LDAP - The Lightweight Directory Access Protocol is a standardized networking protocol designed for querying and modifying directory services.

LDIF - LDAP Data Interchange Format is an ASCII file format suitable for describing directory information or modifications made to directory information. LDIF is typically used to import and export directory information to and from LDAP-based directory servers.

PDU – A Protocol Data Unit is a request or response message in some protocol.

PDUA – The Printing DUA of ViewDS is a directory user agent for extracting data from the directory to produce reports and paper directories.

RXER – The Robust XML Encoding Rules is a set of encoding rules for Abstract Syntax Notation One (ASN.1) that produces an XML representation for data values.

SAML - Security Assertion MarkUp Language. Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee.

SASL – The Simple Authentication and Security Layer is a method for adding authentication support to connection-based protocols.

SDUA – The Stream DUA of ViewDS is a text-oriented directory user agent.

SOAP – Simple Object Access Protocol. Simple Object Access Protocol (SOAP) is a way for a program running in one kind of operating system (such as Windows 2000) to communicate with a program in the same or another kind of an operating system (such as Linux) by using the World Wide Web's Hypertext Transfer Protocol (HTTP)and its Extensible Markup Language (XML) as the mechanisms for information exchange.

WebDUA – The WebDUA of ViewDS is a web browser user interface to the directory for performing queries and updates.

X.500 - X.500 is a series of computer networking standards covering distributed and replicated electronic directory services.
X.509 and X.525 - X.509 is the document in the X.500 series that specifies the Public Key Framework and X.525 specifies replication.

XACML - The eXtensible Access Control Markup Language. It is a declarative access control policy language implemented in XML and a processing model, describing how to interpret the policies. It is an OASIS standards based replacement for IBM's proprietary XML access control language (XACL) which is no longer in development.

XED - The XML Enabled Directory leverages existing 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 and X.500 agents.

XIDM - The XML Internet Directly Mapped protocol (a.k.a. XIDMP) is a completely XML rendition of IDM.

XLDAP – The XML Lightweight Directory Access Protocol is a completely XML rendition of LDAP. All LDAP protocol messages (including extended operations),
LDAP controls and directory data are entirely represented as markup.

XML - The Extensible Markup Language is a W3C recommended general-purpose markup language for creating special-purpose markup languages, capable of describing many different kinds of data.

ViewDS 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 provides web based access through the WebDUA; command line access through the SDUA; printing and report access through the PDUA.

The WebDUA is a web based user interface that provides an out-of-the-box web interface for ViewDS, 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 schema. This task is made simple through the ViewDS Management Agent. The WebDUA of course also leverages the ViewDS 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).

They are:
a) semantically equivalent XML renditions of existing directory protocols,
b) XML renditions of directory data.
c) the ability to accept at run time, user defined attribute syntaxes specified in a variety of XML schema languages.
d) the ability to perform filter matching on the parts of XML format attribute values,
e) 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.

ViewDS' current customers include:
* Defence Organizations
* Australian Government Organizations and Departments
* Large Australian Companies
* International Companies
Click here for a list of some ViewDS clients

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 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 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's support for XML, XACML policies can be stored, validated and indexed within a ViewDS server. This allows ViewDS 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 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.

Yes.

ViewDS 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 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 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 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 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 and utilizing ViewDS' 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 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 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 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's XML searching capabilities, components within an organization that are making policy decisions can use ViewDS to quickly locate policy and user information of interest.

Future enhancements to the ViewDS 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 (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 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.

Currently ViewDS does not support using XPath, however ViewDS allows queries of XML documents through its support for component matching. Future versions of ViewDS will provide support for XPath queries through the DAP, LDAP and XLDAP protocols.

XPath, the XML Path Language, is a query Language for selecting nodes from an XML document. In addition, XPath may be used to compute values (e.g., strings, numbers, or Boolean values) from the content of an XML document.

The XPath language is based on a tree representation of the XML document, and provides the ability to navigate around the tree, selecting nodes by a variety of criteria. It was originally created to provide a common syntax and behavior model between Xpointer and XSLT, which are subsets of the XPath query language and are used in other W3C specifications such as XML schema and Xforms. XPath 2.0 is the current version of the Xpath language defined by the WWW Consortium, W3C. XPath is used primarily for selecting parts of an XML document. For this purpose the XML document is modeled as a tree of nodes. XPath allows nodes to be selected by means of a hierarchic navigation path through the document tree. XPath 2.0 is used as a sublanguage of XSLT 2, and it is also a subset of Xquery 1.0. All three languages share the same data model, type system, and function library, and were developed together and published on the same day. Every value in XPath 2.0 is a sequence of items. The items may be nodes or atomic values. An individual node or atomic value is considered to be a sequence of length one. Sequences may not be nested. Nodes are of seven kinds, corresponding to different constructs in the syntax of XML: elements, attributes, text nodes, comments, processing instructions, namespace nodes, and document nodes. Nodes may be typed or untyped. A node acquires a type as a result of validation against an XML Schema. If an element or attribute is successfully validated against a particular complex type or simple type defined in a schema, the name of that type is attached as an annotation to the node, and determines the outcome of operations applied to that node: for example, when sorting, nodes that are annotated as integers will be sorted as integers. Atomic values may belong to any of the 19 primitive types defined in the XML Schema specification (for example, string, boolean, double, float, decimal, dateTime, QName, and so on). They may also belong to a type derived from one of these primitive types: either a built-in derived type such as integer or Name, or a user-defined derived type defined in a user-written schema.