Identity Apps with NVDS
Novell Cool Solutions: Feature
By Erin Quill
Digg This -
Posted: 21 Jul 2005
This article is adapted from the BrainShare 2005 presentation "TUT 250 - Identity-Enabled Applications with Novell Virtual Directory Services"
Why Directory-Enabled Applications?
Applications can benefit from being directory-enabled in the following ways:
- They model the real world.
- They can share data access from anywhere.
- There is intrinsic access control.
- There is one-to-many management.
But there are still barriers to directory-enabled applications. There are some perceived risks associated with changing or upgrading key infrastructure. Political issues can often be involved, such as when schema extensions are proposed, and data may be inaccessible at times.
Novell Virtual Directory Services
The role that directories play has matured. Enterprise, extranet, and internet-facing directories now face heavy change-control constraints. In response to this, applications need access to centrally stored Identities and the ability to modify that data. The applications also need to store their own app-specific identity data. In short, applications need identity services, but the directory has become a highly protected asset.
NVDS (Novell Virtual Directory Services) addresses these challenges. Below is a diagram of the NVDS flow.
Figure 1 - NVDS flow
Here is the application's view of that flow:
Figure 2 - Application view of NVDS
Benefits of Novell Virtual Directory Services
NVDS has numerous benefits. Here are some of the things that NVDS gives to your application:
- A directory-style private data store
- Ability to store some identity attributes locally while connecting to an existing corporate directory for authentication and authorization
- Ability to support multiple identity stores, such as Novell eDirectoryTM, Microsoft Active Directory, and Sun Java System Directory Server
- Ability for your customers to focus on your application's core value proposition, while avoiding political and technical deployment hurdles
The NVDS vision is: "The customer installs, configures, manages, uses, and even uninstalls an application that embeds NVDS - and never sees NVDS."
The following use cases demonstrate the value of this vision.
Use Case One
You have an opportunity to sell your directory-enabled application into a single department at a Fortune 500 company that is already using eDirectoryTM as its corporate directory.
Problem: Extending the schema for your application in the corporate tree requires corporate-level approval. Furthermore, your application adds attributes to the User object, and corporate IS&T is complaining about it. This has already delayed the sale by two months, and it looks like it will be at least two more months before approval is obtained to deploy the application for this department.
Use Case Two
You want to sell your directory-enabled application into Active Directory shops.
Problem: Customers in these shops are already using Active Directory and don't want to deploy eDirectory. To make matters worse, you'll also require them to install DirXML® drivers between Active Directory and eDirectory to make the application work. Potential customers are asking why your application cannot just use the identities in Active Directory for authentication and authorization decisions without having to install a meta-directory product to bring your product's data and the user identities into a single directory.
Use Case Three
Your product manager tells you that your directory-enabled application has to provide policy and authorization decisions for users and other identities stored in all of the following corporate directories: eDirectory, Sun ONE directory server, Active Directory, and NT Domains.
Problem: Your application also needs a place to store its own configuration and policy information. The directory seems like a perfect place to store it, but the application won't be widely adopted unless it works without making any updates to the corporate directory.
What would eDirectory look like if it were extended to solve these problems?
First, you could embed eDirectory within an application. The schema would be local to the application's instance of eDirectory and wouldn't require updating in a corporate tree. Customers who already have a directory wouldn't have to know (or care) that eDirectory services were enabling the functionality of your application, because these services would be invisible. Customers would just install and manage your application, NOT your application plus eDirectory.
Second, your applications could consume identities from other directories. Application-specific information, such as configuration and policies, could be stored within a private instance of the directory. However, authorization decisions could be made using identities (users, groups, devices) stored in other directories. eDirectory services would glue these disparate directories together. The services would provide a single point of access for all of the application?s directory usage, even when the actual entries are in more than one location.
Here are the basic NVDS features:
- Embeddable Install
- Private Directory
- Identity integration
- Other Services
Each of these features is described in more detail below.
1. Embeddable install
The NVDS embeddable install is:
- Installable anywhere (Windows and NetWare®)
- RPM-based (Linux)
Application vendors have the freedom of choice on how the application will be managed. All management tools are exposed natively via Novell's management framework or through API's that enable vendors to write their own.
The diagram below shows the management structure for NVDS.
Figure 3 - NVDS management structure
NVDS management is primarily done with iManager. Skinnable iManager plugins are available, and you can use the default plug-ins (basic LDAP, object browser, and create integration point). Management tasks such as repair, backup, trace, etc., can be done in NVDS.
As an alternative, you can build your own management console. In this scenario, all configuration, management, maintenance, and diagnostic operations are performed via SOAP. A scriptable command-line tool, as well as a command-line interface.
3. Private Directory
The Private Directory capability fo NVDS gives applications a private data store. This offers the power, flexibility, and features of a directory service without requiring installation of a corporate directory or updates to that directory's schema.
The basic elements of the Private Directory are:
- X.500/LDAP data model
- LDAPv3 support
- Enhanced schema functionality
- Replication (the unit of replication is a NVDS instance, which is roughly analogous to an eDirectory partition)
The embeddable data store is private, supporting application schema and application data. It features a directory-style data store for applications, and it runs in separate process space. Also, multiple NVDS-enabled applications can reside on a single computer.
4. Identity Integration
"Identity integration" gives applications the ability to seamless integrate with a customer's corporate directory infrastructure and the information it stores (typically identity information).
With identity integration, applications can federate with external identity stores. The applications can use identities (users, workstations, etc.) that exist in external identity stores such as corporate directories. These identities are written independent of any specific external identity store, and they can interact with external identity stores in read-only or read/write fashion, based on their needs.
LDAPv3 operations can be chained or referred. All RFC 2256 update and retrieval operations are supported. Also supported are the following LDAPv3 identity stores:
- Active Directory
- Sun ONE
Identity integration enables storing and retrieving attributes on reference entries. You can also make authorization (access control) decisions to NVDS entries using external identities.
5. Other Novell Virtual Directory Services
- A: Authentication Services
- B: Authorization Services
- C: Data Security Services
- D: OS Platform Support
A: Authentication ServicesThe NVDS Authentication Services enable users to securely establish their identity. The following authentication methods are supported:
- Name and password
- SAML assertion acceptance (Coming soon) - this requires prior establishment of a trust relationship with the SAML assertion provider
- Additional methods can be supported more easily via modular design
B: Authorization Services
Authorization Services enable applications to securely make authorization decisions and customize user experience based on user identity. Access control information can be stored on any entry and can be managed by container or group. This information is automatically inherited from superior entries unless explicitly blocked. Security equivalents can be used to grant all members of a group rights in a single operation.
NVDS can make authorization decisions to determine whether a) a local entry has rights to a local entry, or b) a remote entry has rights to a local entry. In case A, the issue could be whether the application's administrative user (whose account is in NVDS) can modify an application policy object. In case B, the issue could be whether a specific employee (whose identity is in the corporate directory service) could use a specific application feature.
Operations performed by NVDS on remote identity stores can use the authenticated user's credentials. This is constrained by the authorization policies of the remote identity store for the user's identity. Operations performed by NVDS on remote identity stores can also depend on a dedicated proxy user. This is constrained by the authorization policies of the remote identity store for the proxy user's identity.
C: Data Security Services
NVDS uses SSL/TLS-based data transmission. This provides data confidentiality and integrity services and is available for all data transmission, including:
- Inbound connections from applications
- Outbound connections to identity stores
- NVDS-to-NVDS connections used for replication
Attribute encryption is defined via the schema - you simply define an attribute type to be encrypted. This protects all values of specified attributes, as only users with explicit rights to the attribute can retrieve values. It also protects sensitive information from inadvertent disclosure (e.g., administrators) and hostile disclosure (e.g., attackers).
D: OS Platform Support
OS support for NVDS on Linux is aligned with the Novell strategy. SUSE Enterprise Server 9 and 9.1, SLES 9, and Red Hat Linux Advanced Server 3.0 are all supported. NVDS is also supported on NetWare 6.5 and Windows 2003 Server.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com