Identity-Enabled Applications with Novell Virtual Directory Services

Jenifer Child

Project Manager

jchild@novell.com

Novell, Inc.

Erin Quill

Product Manager

equill@novell.com

Novell, Inc.

Agenda

Overview

Scenarios

Novell Virtual Directory Services Overview

Why Directory Enabled Applications

Applications benefit from being directory enabled

Model real world

Shared data access from anywhere

Intrinsic access control

One to many management

But there are still barriers

Perceived risks associated with changing or upgrading key infrastructure

Political issues

Inaccessible data

Evolved

Novell Virtual Directory Services

The role directories play has matured.

Enterprise, extranet, and internet-facing directories now face heavy change control constraints.

The classic

Corporate

Directory

Glass House

CHANGES

Novell Virtual Directory Services

Applications

Need access to centrally stored Identities

Need to make modifications to that data

Need to store their own app-specific identity data

Schema
changes

Applications need identity services, but the directory has become a highly protected asset.

Glass House

CHANGES

BDobbs

Password

Telephone #

Address

Novell Virtual Directory Services

All LDAP calls

BDobbs

Preference 1

Preference 2

Application

NVDS

NVDS conjoins the attributes into a single identity for the application

BDobbs

Password

Telephone No.

Address

App Pref 1

App Pref 2

Authoritative Identity requests

Central Identity

The Application's View

End user of the application that has Novell Embedded Identity Broker

Chaining to other directories

NVDS

Request

Result

Request

Result

Result

Request

Request

Result

Directory

Directory

Directory

Other corporate directories

Application

Novell Virtual Directory Services

Gives your application

Its own 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

Novell eDirectory™

Microsoft Active Directory

Sun Java System Directory Server

Allows your customers to

Focus on your application's core value proposition

Avoid political and technical deployment hurdles

Customer Usage Vision

Customer installs, configures, manages, uses, and even uninstalls an application that embeds NVDS and never sees NVDS

NVDS

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 eDirectory™ 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.

Real life use case
Take copiers to the next level

Value add

Security/Authentication

Billing

Auditing

Scanning

Document production

Communication between devices

Consideration

Avoid system and administrator complexity

End user ease of use (not another username/pw)

Work in any existing customer environment

Central Identity

NVDS

Real life use case
Take copiers to the next level

Real life use case
Novell Nsure SecureLogin

Corporate

Directory

Novell Nsure

SecureLogin

Extend Schema

Create Configuration Objects

Verify Secret Store

Create user info

Real life use case
Novell Nsure SecureLogin

Corporate

Directory

NVDS

Solution

What would eDirectory look like if it were extended to solve these problems?

Ability to embed eDirectory within an application

Schema would be local to the application’s instance of eDirectory and wouldn’t require updating schema 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 they would be invisible. Customers would just install and manage your application, NOT your application plus eDirectory.

Solution

Ability to consume identities from other directories

Applications would be able to store application-specific information like configuration and policies within their private instance of the directory, yet they would be able to make authorization decisions using identities (e.g. users, groups, and devices) stored in other directories.

eDirectory services would glue these disparate directories together and provide a single point of access for all of the application’s directory usage—even though the actual entries are in more than one location.

Novell Virtual Directory Services

Embeddable Install

Management

Private Directory

Identity integration

Other Services

Novell Virtual Directory Services

Embeddable install

Silent

Scriptable

Install Anywhere (Windows and NetWare®)

RPM-based (Linux)

Management Vision

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.

Novell Virtual Directory Services

Management

NVDS

NVDS

Web Services

SDK

iManager

Custom

Management

Command Line

Client

Novell Virtual Directory Services

Management

iManager

Skinnable iManager plugins

Default Plug-ins (basic LDAP, object browser, create integration point)

Management Task (repair, backup, trace...)

Build you own management console

All configuration, management, maintenance and diagnostic operations performed via SOAP

Scriptable command line tool

Command line interface

Private Directory Vision

Give applications a private data store that offers the power, flexibility, and features of a directory service without requiring installation of a corporate directory or updates to that directory’s schema, etc.

Private Directory

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

Novell Virtual Directory Services

Embeddable data store

Private

Application schema

Application data

Directory-style data store for applications

Runs in separate process space

Multiple instances

Multiple NVDS enabled applications can reside on a single box

Identity Integration Vision

Give applications the ability to seamless integrate with a customer's corporate directory infrastructure and the information -typically identity information-it stores.

Identity Integration

Applications can

Federate with external identity stores

Use identities (users, workstations, etc.) that exist in external identity stores such as corporate directories

Written independent of any specific external identity store

Interact with external identity stores in read only or read/write fashion based upon their needs

Identity Integration

References

Chain or refer LDAPv3 operations

Support all RFC 2256 update and retrieval operations

Supports LDAPv3 identity stores

eDirectory

Active Directory

Sun ONE

NVDS

Store and retrieve attributes on reference entries

Make authorization (access control) decisions to NVDS entries using external identities

Identity Integration- eDirectory today

Three partitions

Physical data storage may be disjoint

Objects in one partition can authenticate to any other

Privileges can be granted to any object, regardless of physical location

Corp

Dev

Sales

The application utilizes NVDS for directory integration.

Users of the application authenticate using their identities that already exist in Sales and Dev

Privileges to the application services are granted or denied based on ACLs stored within NVDS.

Identity Integration- Novell Virtual Directory Services

Corp

Dev

Sales

App

Other Novell Virtual Directory Services

Authentication Services

Authorization Services

Data Security Services

OS Platform Support

Novell Virtual Directory Services Authentication Services

Allow users to securely establish their identity

Supported Authentication Methods

Name and password

SAML assertion acceptance (Coming soon)

Requires prior establishment of a trust relationship with the SAML assertion provider

Modular to support future additional methods

Novell Virtual Directory Services Authorization Services

Allow applications to securely make authorization decisions and customize user experience based on user identity

Access control information

Can be stored on any entry

Can be managed by container or group

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

Novell Virtual Directory Services Authorization Services

NVDS can make authorization decisions to determine whether

A local entry has rights to a local entry

Example: Can the application's administrative user (whose account is in NVDS) modify an application policy object?

A remote entry has rights to a local entry

Example: Can a specific employee (whose identity is in the corporate directory service) use a specific application feature?

Novell Virtual Directory Services Authorization Services

Operations performed by NVDS on remote identity stores using authenticated users credentials

Constrained by the authorization policies of the remote identity store for the user's identity

Corporate

Directory

NVDS

BDobbs

BDobbs

Novell Virtual Directory Services Authorization Services

Operations performed by NVDS on remote identity stores using dedicated proxy user.

Constrained by the authorization policies of the remote identity store for the proxy user's identity

Corporate

Directory

NVDS

BDobbs

Dedicated Proxy User

Novell Virtual Directory Services Data Security Services

SSL/TLS based data transmission

Provides data confidentiality and integrity services

Available for all data transmission

Inbound connections from applications

Outbound connections to identity stores

NVDS-to-NVDS connections used for replication

Novell Virtual Directory Services Data Security Services

Attribute encryption

Defined via schema

Simply define an attribute type to be encrypted

Protects all values of specified attributes

Only users with explicit rights to the attribute can retrieve values

Protects sensitive information from

Inadvertent disclosure (e.g. administrators)

Hostile disclosure (e.g. attackers)

OS Support

Linux – aligned with Novell strategy

SUSE® Enterprise Server 9 and 9.1

SLES 9

Red Hat Linux Advanced Server 3.0

NetWare 6.5

Windows 2003 Server

Summary
Novell Virtual Directory Services

Enables your application

Its own 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

Novell eDirectory™

Microsoft Active Directory

Sun Java System Directory Server

Allows your customers to

Focus on your application's core value proposition

Avoid political and technical deployment hurdles

General Disclaimer

This document is not to be construed as a promise by any participating company to develop, deliver, or market a product. Novell, Inc., makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.

No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.

This means that no work is lost with either the Novell Nsure UDDI corporate or testing solution.

Enterprises that build their UDDI solutions with Novell Nsure UDDI Server, are not only leveraging the deep experience Novell Identity Management foundation brings to the standard, they are securing their own future by building on an open standard implementation that will grow and scale with their corporate needs.

2003-12-08T12:43:39