Why LDAP in E-Business?

1. Why LDAP in E-Business? Guy Huntington, President, HVL Derek Small, President Nulli Secundus

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

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

4. Today’s Challenge • Common identity management • Coordinated authentication • Coordinated authorization • Securability • Scalability • Performance

5. 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?

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

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

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

9. Authentication Data Stores • Different authentication for different systems • Often username and password related • Too many passwords • Too many usernames • Too much confusion

10. Single Sign On • Ease of use • Maintain security integrity • Response barriers • Hashed values • Non hashed values • Different values • Different usernames

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

12. 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?

13. Enter Directories! • Fast reads not fast writes • Hierarchical vs. relational • Best in stateless or semi-stateless environments • Easily partitioned • Operate to standards

14. L.D.A.P. • Lightweight Directory Application Protocol • Offspring of x.500 • Internet Engineering Task Force (IETF) standard

15. Databases vs. Directories • Databases • Stateful processes like transactions • Fast writes • Storing large amounts of information • Relational information querying

16. Databases vs. Directories • Directories • Non-stateful or semi stateful processes like identity management • Fast reads • Smaller amounts of information • Hierarchical information

17. Attributes • Stores basic information such as: people, places and things • Starts with traits about a specific object • Each trait is called an “attribute”

18. Entry • An entry describes a person, place or thing • Each entry contains attributes describing the entry’s traits

19. Object Classes • Groups like attributes together • Can have sub-classes of object classes to further refine groupings • Sub-classes inherit attributes from parents

20. Schema • Next up are the rules defining what defines attributes, object classes and how they’re used • This is called the “Schema”

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

22. DIT Naming Conventions • Groups of entries are designated by monikers • dc=acme (domain container) • ou=people (organizational unit) • ou=employees • uid=Ghuntington (unique identifier)

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

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

25. dc=acme ou=people, dc=acme ou=employees,ou=people,dc=acme uid=Ghuntington,ou=employees,ou=people,dc=acme An Example

26. 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=

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

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

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

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

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

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

33. Single Sign On • Requires a directory strategy • Requires infrastructure tools • Very expensive, difficult, complex and time consuming if you don’t

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

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

36. Who Makes “Infrastructure Glue”? • Oblix • Netegrity • IBM/Tivoli • Entrust • Others

37. Knitting the Systems • Like a jigsaw puzzle • LDAP, directory strategy and companies like Oblix are the infrastructure glue you require

38. Benefits • Significant competitive advantage • Increased profitability • Enhanced corporate responsiveness • Enhanced and uniform security processes • Ease of use

39. Directory Project ROI • Generally 5-7 times investment • Savings come from labor, productivity and business process savings

40. Requirements • LDAP directory design experience • Web security background • System integration • HRIS integration experience • Infrastructure tools experience

41. Other E-Business Presentations • http://www.hvl.net/ebusiness.htm

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