Transcript Blank 2002 Template

Preparing Your Directory
Infrastructure for the Internet
Age
www.novell.com
Vikas Mahajan
Senior Consultant
PriceWaterhouseCoopers
[email protected]
Overview
• Overview
 PwC
“DNA” of Identity Management
 Different spaces for different directories
 What LDAP is and isn’t
 Directories and databases
 Using directories in the Internet space
 Directory design for the Internet
 Directory management considerations
 Meta-directory
 Identity management
PwC “DNA” of Identity Management
Business Objectives
Management Commitment
Intrusion Detection
Permission
& Policy
Management
Strong
User
Provisioning
Enterprise
Directory
Workflow
Network Security
Policy
Enablers
Authentication
Enterprise Directory—Identity
Management Infrastructure
Solution
Enterprise
Directory
Enterprise directories have become the industry standard for accessing common user
directory information. LDAP has been embraced and implemented in most networkoriented middleware. As an open, vendor-neutral standard, LDAP provides an
extendable architecture for centralized storage and management of information that
needs to be available for today's distributed systems and services.
Business Issues
•
•
•
•
What content should be stored in my directory verses other repositories?
How do I unify and consolidate my user repositories?
How do I determine authoritative sources and ensure ongoing data quality?
How do I manage the user information for multiple user communities
(e.g., business partners, customers, vendors, and employees)?
Technical Issues
• To be discussed in this presentation
Directory Spaces
• Not all directories are alike
• Many are suited to particular services or apps
• While it may technically be possible to use any
LDAP compliant directory, consider the strength
and weakness of each directory and their
suitability to roles in spaces where they do not
have a strong presence
• There will always be more than one directory in
your environment
Directory Spaces Defined
• NOS (Network Operating System)
 Directories
that are tied to an operating system and
provide client/server directory access
•
•
•
•
Desktop authentication for file/print services
Application distribution
Desktop management
Network infrastructure management
• Messaging
A
directory service primarily serving as the user
repository for a messaging/e-mail/groupware
application
Directory Spaces Defined
(cont.)
• Internet
 Directories
that are primarily used for
authentication, authorization, and personalization of
Internet based applications and services
 Applications include Portals, B2B, B2C, and B2E,
“eBusiness”
 Emphasis on speed and scalability
Directory Spaces and Vendors
LDAP—What You Need to Know
• Lightweight Directory Access Protocol
 LDAP
is a IETF ratified standard protocol for accessing
data stored in X.500 like directory databases
 If a product can accept LDAP protocol based
requests, the vendor may call it LDAP compliant
 The more accepted understanding of LDAP includes
several IETF standards that define additional features
including a file exchange format (LDIF) and certain
object class and attribute definitions (inetOrgPerson)
LDAP—What You Need to Know
(cont.)
• When choosing a directory product



Ensure that it complies with all LDAP standards to ensure
compatibility with LDAP compliant Directory enabled
Applications
Remember that LDAP standards do not specify the database to
be used as the data repository
LDAP standards do not address a wide variety of
directory/database components and features:
• Partitioning and replication
• Indexing
• Backup
• Referrals
LDAP—What You Need to Know
(cont.)
• When choosing a directory product


Examine the underlying data store to ensure the database
has the features you need (partitioning, replication,
referential integrity, scalability, data integrity, performance,
etc.)
Look at ALL the protocols, languages and standards the
directory supports—LDAP may not be enough for your needs
•
•
•
•
X.500
XML/DSML—Directory Services Markup Language
ODBC/SQL
Other protocols/languages used by your developers
Directories and Databases
• Directories
 Read-optimized
 Store
relatively static data
 Object-oriented
 Hierarchical
 Distributed
 Support multi-valued attributes
 Support replication
 Extensible schema
Directories and Databases
(cont.)
• Relational databases
 Designed
for write-intensive operations
 Either storing data in flux or historical data
 Application-specific schema
 Support complex data models
 Data integrity a top consideration
 ACID transaction—Atomic, Consistent, Isolated,
Durable
Directories and Databases
(cont.)
• Directories and databases—complementary
 Each
is suited for particular types of tasks
 Directories are perfect for authentication,
authorization, storing personal information that is
relatively static and used by a variety of applications
 Databases perform transactions, store applicationspecific data, store BLOB data
 Directories and databases work together to solve
business problems
Directories and Databases
(cont.)
• A Directory on top of a database?
 Some
directory vendors have built LDAP compliant
directory applications on top of an RDBMS—IETF
standards do not dictate a data store for LDAP
directories
 Note that database vendors have therefore embraced
and adopted directory technology
 Think of the RDBMS as just another platform upon
which your directory can sit; some sit on top of a
particular OS, others on top of a particular RDBMS
Directories and Databases
(cont.)
• A Directory on top of a database?
 Realize
there are many challenges to implementing a
directory on top of an RDBMS—overcoming those
challenges requires careful examination of
•
•
•
•
•
•
•
Performance
Partition/replication/distribution
Security
Schema extensibility
Support for hierarchy
Translation of LDAP queries to SQL
Support for multi-valued attributes
Directories and the Internet
• Directories in the Internet space
 Authentication
• Provide verification of your identity
 Authorization
• What you are entitled to see or do
 Personalization
• Pieces of data specific to you—identification, preferences,
tastes, etc.
Directory Design
Old Rules
• Users with the same CN
existing in different parts
of the tree
• Your tree was
hierarchical, designed for
efficient WAN
performance
• Only minimum required
attributes had values
New Rules
• Unique Object Names;
every object should have
a unique CN or UID
• Your tree may be flat or
hierarchical, but is likely
to be centralized or
distributed over highspeed links
• There will be many
attributes with values
Directory Design
Old Rules
• One tree
• Upgrade DS with the OS
• Never extend the schema
on your own
• Directory servers same as
File/Print servers
(cont.)
New Rules
• More than one directory
• DS upgrade independent
of OS, determined by
application support
• Extend the schema to
provide new attributes
and object classes
• Dedicated directory
servers
Directory Design
(cont.)
Can you use your existing tree?
• Do your users have unique IDs (unique CN)?
• Are you running eDirectory 8.5 or higher? Is the same
version of the DS database used across all servers?
• Are there servers that hold all user replicas?
• Do you want to use DNS Federation?
• Are you using Delegated Administration? If so, are you
comfortable with others (inside or outside your company)
managing users and groups within your tree?
• Can your current directory infrastructure handle
replication traffic for many new attributes?
Directory Design
(cont.)
• B2E Tree
PARENTCO
USERS
DIVISION1
User1
DIVISION2
User2
PORTAL
DIVISION3
User3
POLICIES
GROUPS
CHILDRELATIONS
PARENTRELATIONS
portalgroup1
portalgroup1
portalgroup1
Directory Design
(cont.)
• B2E Tree
• Users exist under a common location, subdivided
by business divisions
• Ideal for delegating administration, replicating
based on division
• Portal specific objects in one container
• Security policies for a security application in a
special container (policy store)
Directory Design
• B2B Tree
(cont.)
Directory Design
(cont.)
• B2B Tree
• Hierarchy reflecting business relationships—parent
company, followed by divisions
• Designed for delegated administration by each company
or division—reduce administration overhead
• Permissions to applications provided by your company
controlled by application groups
• Use “nested groups”—Division A DA adds user to group1
under division A and this group is a member of application
1, so users automatically get appropriate permission to
access applications
Directory Design
• B2C Tree
(cont.)
Directory Design
(cont.)
• B2C Tree
• Self-registration
• Simple to setup and maintain—best to use if you
don’t have data that will allow you to organize
users
• Ensures unique names for all users
Guidelines for Extending the Schema
Analysis
• Examine the data—store relatively static data in
the directory and avoid BLOB data
• How is the data used or accessed—What question
is being asked of the directory?
• User attribute vs. Group object
Guidelines for Extending the Schema
Design
• Use existing attributes
 Few
custom attributes—map to existing attributes
 Many new attributes—create new attributes, define
new object class
 Inherit from existing object classes
• Class types
 Effective
(structural)
 Ineffective (abstract)
 Auxiliary
Directory Management Staffing
Considerations
•
•
•
•
The directory is an application
Many applications depend on the directory
Consider hiring a full-time directory staff person
Directory experts need to understand LDAP standards,
tree design, data synchronization, meta-directory,
security, and the applications that utilize the directory
• They need to work with application developers, DBAs,
security staff, network infrastructure, Human Resources,
software vendors
Directory Management Duties
•
•
•
•
•
•
•
•
•
•
•
Determine where to store data—directory or database
Determine how to store data—attribute vs. group vs. OU
Determine where and how to get the data
Cleanse and import data
Synchronize/maintain data
Secure the directory and the data
Integrate applications
Replication/partitioning/fault tolerance/backup
Multi-directory management
Single sign-on
Provisioning
Meta-Directories
• Applications designed to allow different
•
•
•
•
repositories of user information to share data
Help to ensure data is consistent and accurate
across the enterprise
Can be used to automate account
creation/deletion
Synchronize data without compromising
authoritative sources of information
Enforce standards—naming standards, data
formatting standards, etc.
Meta-Directories
• Some meta-directories have a centralized data
repository
 This
may be a directory you already have or a new
directory created by the meta-directory software
• Some meta-directories use no directory at all—
“Virtual Directory”
• Meta-directories are NOT password
synchronization or SSO solutions
PwC “DNA” of Identity Management
Business Objectives
Management Commitment
Intrusion Detection
Permission
& Policy
Managemen
t
Strong
User
Provisioning
Enterprise
Directory
Authentication
Workflow
Network Security
Policy
Enablers
PwC Approach—Identity Management
Infrastructure
Solution
Permission &
Policy
Management
Privilege Management Infrastructure engines are security solutions
for integrating single sign-on, user authentication/ authorization/
entitlements, and application personalization within HTTP
environments. These products can integrate with standards-based
user directories making it possible to manage a significant portion of
your web access control components from a single console. Most
security middleware engines are fully redundant, allowing for
massive scalability and high availability.
Business issues
•
•
•
•
How do I solve multiple authentication requirements for my web apps?
How do I deploy a common authorization and entitlements model?
How do I create a redundant, highly scalable web SSO architecture?
How do I open up access to my corporate intranet for my business
partner network?
• How do I create a secure Employee Self Services model for my
employees?
PwC Approach—Identity Management
Infrastructure (cont.)
Solution
Strong
Authentication
Strong authentication mechanisms combine multi-factor techniques
to validate an individual’s identity
A tiered approach to strong authentication can include a combination of:
 User ID and password
 Challenge response
 Hardware/software tokens
 Digital certificates
 Biometrics
Business issues
•How do I authenticate a web user using a two-factor authentication model?
•How do I manage and operate my SA infrastructure?
•How do I integrate SA into my overall identity management infrastructure?
PwC Approach—Identity Management
Infrastructure (cont.)
Solution
User
Provisioning
Workflow
User provisioning automates many of the traditionally manual processes
and procedures required to manage users access to resources across the
enterprise.
Workflow is the process of automating the business rules and approval
process required to grant users access to an organization’s resources.
Combining the two allows an organization to automatically and quickly
grant or deny access to users with a minimal of manual intervention or
manual approvals.
Business issues
• How do I manage the multitude of user accounts for my
employees, customers, business partners?
• How do I quickly and efficiently remove a user’s access to all of
the corporate systems that they have access to ?
• How do I approve a user’s access to several systems?
PwC Approach—Identity Management Infrastructure
IDM Infrastructure Detailed Deployment Framework
Manage Project and Project Scope
- Program Office
- Project Plan
- Internal Project Communications - Success Measures
Define Overall IDM Blueprint and
Integration Approach
• Tech Arch/Infrastructure
• Security
• Directory Schema/DIT
• User Mgt Model
• Support
Develop IDM Vision and Build Teams
Define Business
Case
And ROI Models
Assess Current
Capabilities:
• Competencies
• Policies
• Training
Assess Current
Landscape:
• Network
• WEB Apps
• Legacy Apps
• Security
• Authoritative
User Store(s)
• User Roles and
Security Profiles
As-Is Workshops
Customize
Application
Integration
Toolkit
Define &
Prioritize
Application
Integration
Timeline
Develop IDM
Demo
Develop
IDM Strategy
Documents &
Presentation
To-Be
Workshops
Define Communications Strategy
Plan Future
Releases
Design
Tech Arch
& Infrastructure
Select Enabling
Technologies
Create
Integration
Roadmap
Develop
Proof
of concept
Design
Application
Security
Solution
Develop Infrastructure & Directory
Design User
Directory
Solution
Develop User Mgt Applications
Design Data Mgt
Solution
Design
Conversion and
Interfaces
Design
Enabled User Mgt
Processes
Technical Team Training
Integrate Application(s) & Portal(s)
Convert User Data
Define
Testing
Approach
Test Portal
• System Integration Testing
• Performance Testing
• User Acceptance Testing
Define
Testing
Scripts
User Training
Design Ongoing
Security Ops
Support
Implement Ongoing IDM Operations Support
Design
Communications
Methods
Communicate and market new IDM
Identify Opportunities for Next Release
Define Governance
Model
Evaluate
Launch!
Define
Work
Implement
Design & Pilot / Development
Implementation Strategy & Implementation Plan Deliverables
People
Process
IDM Technology
Project
Governance
Start Up
Transition and Implementation
Strategy & Architecture
Development
Novell and PwC Strategy
Novell’s One Net Strategy
Novell Labs
Novell Consulting Services
Management
Commitment
BorderManager®
Intrusion Detection
NAM/NDSAS
eDirectory™
NAAS
Permission
& Policy
Managemen
t
Strong
DirXML™
User
Provisioning
Directories
eDirectory
SecureLogin
Novell Education
Novell/PwC Consulting Services
Novell Technical Support
NMAS
Workflow
SSL, BorderManager, iChain®
eDirectory
Policy
Novell/PwC Consulting
eDirectory
AuthenNMAS
tication SecureLogin
Metastorm
eWork
Network Security
Novell/PwC Consulting
LDAP
SSL
XML
IP
XSLT
PKI
PricewaterhouseCoopers
Strategic Relationships and Technology Experiences
PricewaterhouseCoopers remains vendor independent in order to provide our customers with the most
up-to-date and flexible technology to fit the solution set that is most appropriate for their needs.