420 likes | 532 Views
Why LDAP in E-Business?. Guy Huntington, President, HVL Derek Small, President Nulli Secundus. Today’s Mixed System Reality. ERP’s/HRMS’s/HRIS’s/Financials/Payroll Operating Systems Web Servers Portals Data warehouses Firewall products
E N D
Why LDAP in E-Business? Guy Huntington, President, HVL Derek Small, President Nulli Secundus
Today’s Mixed System Reality • ERP’s/HRMS’s/HRIS’s/Financials/Payroll • Operating Systems • Web Servers • Portals • Data warehouses • Firewall products • Many other systems including manufacturing, distribution, marketing, telephony, facilities, etc.
E-Business Models Require • Enabling customers and business partners’ employees to drill into back office systems • Integrating systems internally • Integrating systems externally with business partners • Customer/Consumer interfaces to internal and external systems
Today’s Challenge • Common identity management • Coordinated authentication • Coordinated authorization • Securability • Scalability • Performance
Comparing Information • An identity purporting to be “Guy” appears • Do we know an identity named “Guy”? • Can we authenticate “Guy”? • If successful, what’s “Guy” authorized for? • Is what he’s authorized for, acceptable for the resource/application/transaction required?
Identity Data Stores • Each stores identity information differently • Length • Syntax • International characters, upper and lowercase • Naming conventions • First name, last name, common name, initials • Initials allowed/not allowed, common name used/not used, full name vs.first name etc.
Identity Data Stores Titles • Used, not used, abbreviated, entered differently • Guy Huntington Human Resource Manager • G. Huntington Human Resource Manager • Guy R. Huntington HR Manager • G. Huntington HR Mgr. • G. Huntington Mgr HR
Identity Data Stores • Entry of the identity into different systems by different people often done manually • Guy Huntington • Guy Huntingdon, HR Manager • Guy Huntington, HRManager • G. Huntindon, Human Resource Manager
Authentication Data Stores • Different authentication for different systems • Often username and password related • Too many passwords • Too many usernames • Too much confusion
Single Sign On • Ease of use • Maintain security integrity • Response barriers • Hashed values • Non hashed values • Different values • Different usernames
Relational Databases • Challenged to perform extremely fast reads • Geared to fast writes • Access by non-web standard protocols • Difficult to partition and manage distributed fail-over • No standards for storing information
Knitting it Together • “How Do I Knit This Together?” • What is the “infrastructure glue” to join the systems at the identity, authentication, authorization and auditing levels?
Enter Directories! • Fast reads not fast writes • Hierarchical vs. relational • Best in stateless or semi-stateless environments • Easily partitioned • Operate to standards
L.D.A.P. • Lightweight Directory Application Protocol • Offspring of x.500 • Internet Engineering Task Force (IETF) standard
Databases vs. Directories • Databases • Stateful processes like transactions • Fast writes • Storing large amounts of information • Relational information querying
Databases vs. Directories • Directories • Non-stateful or semi stateful processes like identity management • Fast reads • Smaller amounts of information • Hierarchical information
Attributes • Stores basic information such as: people, places and things • Starts with traits about a specific object • Each trait is called an “attribute”
Entry • An entry describes a person, place or thing • Each entry contains attributes describing the entry’s traits
Object Classes • Groups like attributes together • Can have sub-classes of object classes to further refine groupings • Sub-classes inherit attributes from parents
Schema • Next up are the rules defining what defines attributes, object classes and how they’re used • This is called the “Schema”
Directory Tree “DIT” • The relationships of entries placed in a directory forms the Directory Information Tree or “DIT” • The higher in the tree you go the more generic the groupings • The most granular information is at the bottom of the tree
DIT Naming Conventions • Groups of entries are designated by monikers • dc=acme (domain container) • ou=people (organizational unit) • ou=employees • uid=Ghuntington (unique identifier)
Distinguished Name • Each entry must have a way in which it can be distinguished from another • Thus LDAP creates a naming convention for “Distinguished Name” or DN
Distinguished Name • To create a DN you look at the entry from the bottom of the tree and then read upwards • DN: uid=Ghuntington,ou=employees,ou=people,dc=acme
dc=acme ou=people, dc=acme ou=employees,ou=people,dc=acme uid=Ghuntington,ou=employees,ou=people,dc=acme An Example
Guy Huntington’s Entry DN: uid=Ghuntington,ou=employees,ou=people,dc=acme Objectclass=people cn:Guy Huntington sn:Huntington telephonenumber: 111-111-1111 userpassword:{SHA}YbMTa6K=
Exchanging Schemas • Enterprises may choose to exchange schemas • Attributes and object classes are thus defined the same • Have a common format for exchanging identity and authentication information
Stateless & Semi-Stateless • Whereas transactions are stateful, identity information is much less stateful • This doesn’t mean writes to a directory can’t take place immediately • Determined by system designers
Master/Child Relationships • PeopleSoft or SAP HR Module may be authoritative source for many identity attributes • Changes first made in the HR module are then replicated out to the directory
Master/Child Relationships • In other instances a network change to an identity may be picked up by the HR module • Provides a flexible framework for your system integration
Is That It? • No! • Directories are useful common data stores with many excellent features • They do not intuitively show relationships of the information • They’re not end user friendly on their own
Identity Management • Streamlined business processes • Provisioning • Delegate identity admin • Down to self serve level if required • View, Access and Notify privileges on an attribute by attribute basis • User friendly search interfaces • Contact look-ups • Location information
Single Sign On • Requires a directory strategy • Requires infrastructure tools • Very expensive, difficult, complex and time consuming if you don’t
Single Sign On Example • SAP/PeopleSoft ERP is tied to the directory for central authentication • ERP’s/HRMS are authoritative source for many identity attributes • ERP’s hold the authorization for the modules you’ve implemented • Directory holds authentication for portal application • Portal holds some authorization for portal apps
Single Sign On Example • Directory holds authorization for other apps for which you don’t have or the authorization is inadequate • Match uniform enterprise authentication schemes to resources/application • Might use username and password for entry level authentication, certificates/smart cards or biometrics for more sensitive apps/information
Who Makes “Infrastructure Glue”? • Oblix • Netegrity • IBM/Tivoli • Entrust • Others
Knitting the Systems • Like a jigsaw puzzle • LDAP, directory strategy and companies like Oblix are the infrastructure glue you require
Benefits • Significant competitive advantage • Increased profitability • Enhanced corporate responsiveness • Enhanced and uniform security processes • Ease of use
Directory Project ROI • Generally 5-7 times investment • Savings come from labor, productivity and business process savings
Requirements • LDAP directory design experience • Web security background • System integration • HRIS integration experience • Infrastructure tools experience
Other E-Business Presentations • http://www.hvl.net/ebusiness.htm
I’d Like to Learn More Guy Huntington, HVL: • guy@hvl.net • www.hvl.net • 604-921-6797 Derek Small, Nulli Secundus • derek@nulli.com • www.nulli.com • 403-270-0657