- Slides: 49
Web Services Directories W 3 C Web Services WS 4/11/01 Scott Isaacson sisaacson @novell. com
What are Directory Services? Registry for the network • • Information about all entities on the network People, Applications, Businesses, Services, Devices, etc. Roles, Relationships, Preferences Configuration and Management Works like the old telephone directory • Find resources by name, type, category, service description
Analogy Standalone OS = Application = Node Network Without a Directory Registry With a Directory
Characteristics of Directory Services Distributed • Global Access • Not a single, central database Replicated • Optimized for local access Secure • Authentication • Authorization • Act in “identity” or “role”
Characteristics of Directory Services ( cont. ) Hierarchical • All Services (from the Root) • All Services local to a Department (from a Container) • All Services in my group (from my Container) Filtered Searches • All Services to which I have access • All color printers • All users logged in with cell phones
Why XML and directories? Directory Service Access Protocols • Proprietary: NDAP (Novell Directory Access Protocol) • Open: LDAP (Lightweight Directory Access Protocol) • Emerging: DSML (Directory Services Markup Language) XML is a natural fit for: • Query – Find all Users with Surname “Isaacson” • Operations – Add User Name=“Scott Isaacson” • Events – Deleted User DN=“Users/ SIsaacson ”
Directory Services: A Web Services Proposal for DSML 2. 0 based on Dir. XML research URL for view and download: http: //www. novell. com/products/nds/dirxmldtddocs. zip Dir. XML is a tools for synchronizing directory information between directories that have • Different schemas • Different administrative tools sets • Different access protocols (even non-LDAP!)
Dir. XML Example: 1. Name Change into HR Subscriber Channel Publisher Channel HR Marketing 2. Driver publishes event Partner Database Sales Dir. XML Legacy Database Payroll Accounting Enterpirse Directory Note: File system, Security, etc. rights all remain intact on moves 3. Dir. XML syncs all directories 4. Other sources of data modifications
What is the proposal? A working DTD that defines document structure for: • Commands • Events Rules (Optional - out of scope? ) • Schema Mapping (User vs inet. Org. Person ) • Matching ( Subtree A match X and Y, Subtree B just match X) • Create ( Subtree A always add X) • Placement (Place P in Subtree A, Place Q in Subtree B) Rules can be done via XSL/XSLT stylesheets
What is the proposal? ( cont. ) A payload (service definition) that needs a truck (protocol) • XMLP • Optional encoding for LDAP? Not a module, but an application • Use XMLP core plus some extension modules • Perhaps RPC Not schema or back-end protocols at this point • IETF started with LDAP • Moved to Extensions, LDUP, etc.
Two types: Input vs. Output There are two basic types of XML documents: • Input documents – Contain exactly one <input> element. – Send commands to a directory – Send events from a directory • Output documents – Contain exactly one <output> element. – Respond to an input with status or data
Input/Output DTD Fragments <!ELEMENT input (add | modify | delete | rename | move | query-schema | add-association | modify-association | remove-association | init-params | status | check-password)*> <!ELEMENT output (status | add-association | modify-association | remove-association | instance | schema-def | init-params)*>
<input> <add> Example Command to the directory to add a User <input> <add class-name="User" src-dn="UsersJulia" dest-dn="cn=Julia, o=Users" event-id="0"> <add-attr-name="Surname"> <value type="string">Gulia</value> </add-attr> </add> </input>
<output> <status> Example Response from the directory <output> <status event-id="0" level="success"/> <add-association dest-dn="UsersJulia">Julia. Gulia 1</add-association> </output> event-id is like “correlation id” - it can be in the underlying protocol!
Events vs. Commands The <add>, <modify>, <delete>, <rename>, and <move> elements represent both commands and events. • • Commands and events have essentially the same syntax. Commands specify that an action should be performed. Events report that something happened. Interpretation depends on context: – Events are sent FROM the directory – Commands are sent TO the directory – When an events are sent, analysis based on the rules, yields no further action or commands that need to be issued
<input> Events and Commands Events and commands that can be children of an element include: • • • <input> <add> <modify> <delete> <rename> <move> <query> • Other allowed children of <input> are not usually interesting except to driver writers.
<output> Responses Events and commands that can be children of an element include: <output> • <status> • <instance> • <add-association> • Other allowed children of <output> are not usually interesting except to driver writers.
Common Attributes common to many events and commands include: • class-name - The name of the base class of the object. • dest-dn - The DN of the target object for commands. • dest-entry-id - The entry id of the target object for commands. • event-id - An identifier used to tag the results of an event or command. • src-dn - The DN of the source object for events. • src-entry-id - The entry id of the source object for events. • timestamp - Reserved for use by the Dir. XML engine.
Common Elements Content elements that are common to many events and commands include: • <association> • <value> • <component>
<association> <!ELEMENT association (#PCDATA)> <!ENTITY % Assoc-State "not-associated | disabled | migrate | pending | manual"> <!ATTLIST association state (%Assoc-State; ) #IMPLIED> • The content of an <association> element is a unique key provided by the application identifying the source object of an event or the target object of a command. • The key is used to associate objects in the directory with an object in another application • The state attribute is used internally for control purposes.
<value> <!ELEMENT value (#PCDATA | component)*> <!ENTITY % Attr-type "string | tele. Number | int | state | counter | dn | interval | octet | time | structured"> <!ATTLIST value type (%Attr-type; ) #IMPLIED association-ref CDATA #IMPLIED naming (%Boolean; ) "false" timestamp CDATA #IMPLIED>
<value> (cont. ) • The type attribute is used to determine how to interpret the <value> content: – "octet" values will contain base 64 -encoded binary data. – "structured" values will consist of one or more <component> elements. – All other value types use a simple string representation of the value. • Looking for a standard for encoding – Should be extensible
<component> <!ELEMENT component (#PCDATA)> <!ATTLIST component name CDATA #REQUIRED association-ref CDATA #IMPLIED> • <component> elements are used to separate the individual fields of structure- or list-based attribute values. • The name attribute depends on the attribute syntax being represented. • The association-ref attribute is used in conjunction with components that are referential.
<value> Example <value> elements: • "string" <value type="string">Fred</value> • "octet" <value type="octet">RM 8 FFy. P 21 kirzwq. Ljr+Q 6 g==</value> • "structured" <value type="structured"> <component name="protected. Name">[All Attributes Rights]</component> <component name="trustee" association-ref="cn=b, o=n">TREEOAdmin</component> <component name="privileges">2</component> </value>
<status> A <status> element: • Is used to return the status of processing a command or event. • The absence of a <status> element in the return document is considered to be an implicit success status. • More than one <status> element can be returned as a result of a given event or command.
<status> DTD Fragment <!ENTITY % Status-Level "fatal | error | warning | success | retry"> <!ELEMENT status ANY> <!ATTLIST status level (%Status-Level; ) #REQUIRED event-id CDATA #IMPLIED>
<status> Example <status event-id="0" level="success"/> <status event-id="1" level="warning">Operation vetoed by Placement Rule</status> <status event-id="2" level="error">ERR_NO_ACCESS</status>
<add> Example When user "Julia" is added to an application the driver reports the following event: <add class-name="User" src-dn="UsersJulia" event-id="0"> <association>JG 0 U 812</association> <add-attr-name="Surname"> <value type="string">Gulia</value> </add-attr> </add>
<modify> Example If the Surname attribute value of user "Julia" is changed from " Gulia" to " Imbruglia " in the application the driver will report the following event: <modify class-name="User" src-dn="UsersJulia" event-id="0"> <association>JG 0 U 812</association> <modify-attr-name="Surname"> <remove-value> <value type="string">Gulia</value> </remove-value> <add-value> <value type="string">Imbruglia</value> </add-value> </modify-attr> </modify>
<rename> Example If user "Julia" is renamed to " JImbruglia " in an application the driver reports the following event: <rename class-name="User" src-dn="UsersJImbruglia" old-src-dn="UsersJulia" event-id="0"> <association>JG 0 U 812</association> <new-name>JImbruglia</new-name> </rename>
<move> Example If user " JImbruglia " is moved from the "Users" container to the " Admins " container the driver reports the following event: <move class-name="User" src-dn="AdminsJImbruglia" old-src-dn="UsersJImbruglia" event-id="0"> <association>JG 0 U 812</association> <parent src-dn="Admins"> <association>Admins</association> </parent> </move>
<query> Content unique to <query> elements: • • Base object (can be a container or subtree ) Root of a hierarchical namespace All objects for a flat namespace. Zero or more <search-class> elements limit scope – Multiple <search-class> elements is “OR”. • Zero or more <search-attr> elements limit scope – Multiple <search-attr> elements is “AND”. • Zero or more <read-attr> elements specify return value(s) – If no <read-attr> elements are present then all – If only a single <read-attr> element with no attr-name then none • A single <read-parent> element indicates that information about the object's parent container is to be returned
<query> Example 1 Search the subtree rooted at "TREENovell" for objects of class "User" with a Surname value of "Jones"; don't read any attributes: <query class-name="User" event-id="0" dest-dn="TREENovell" scope="subtree"> <search-class-name="User"/> <search-attr-name="Surname"> <value type="string">Jones</value> </search-attr> <read-attr/> </query>
<query> Example 2 Read the object of class "User" whose foreign key value is "1011"; read the Surname, CN, Given Name, and Telephone Number attribute values: <query class-name="User" event-id="1" scope="entry"> <association>1011</association> <read-attr-name="Surname"/> <read-attr-name="CN"/> <read-attr-name="Given Name"/> <read-attr-name="Telephone Number"/> </query>
<query> Example 3 Return the current state of all objects : <query event-id="2" scope="subtree"/>
<instance> Zero or more <instance> elements are contained in the response to a query.
<instance> DTD Fragment <!ELEMENT instance (association? , parent? , attr*)> <!ATTLIST instance src-dn CDATA #IMPLIED src-entry-id CDATA #IMPLIED class-name CDATA #REQUIRED event-id CDATA #IMPLIED> <!ELEMENT attr (value*)> <!ATTLIST attr-name CDATA #REQUIRED>
<instance> Content unique to <instance> elements: • Zero or more <attr> elements indicate the current state of attribute(s) of the object. • Zero or one <parent> element contains a reference to the parent object.
<instance> Example <instance class-name="User" src-dn="UsersSamuel"> <association>1012</association> <attr-name="Surname"> <value>Jones</value> </attr> <attr-name="CN"> <value>Samuel</value> </attr> <attr-name="Given Name"> <value>Samuel</value> </attr> <attr-name="Telephone Number"> <value>555 -1212</value> <value>555 -1764</value> </attr> </instance>
<delete> Example If user " JImbruglia " is deleted the driver reports the following event: <delete class-name="User" src-dn="AdminsJImbruglia" event-id="0"> <association>JG 0 U 812</association> </delete>
Some Practical Applications Zero Day Start • Employee joins the company • Fills out an employment contract on the web • All of the following services are enabled, automatcially : – – – – Payroll Phone Facilities Access Information Access Benefits Enrollment Group Memberships Training Etc.
Some Practical Applications ( cont. ) Single Sign On (Authentication Services) • • Authenticate to the network No need to re-authenticate to each service/web site Secret Store: No admin access End User Human retains control if information access – Buying patterns – Information Access • Coming Soon • LDAP over SSL requests • Potential • XML for credentials (attributes, content)
Login Experience: Before Application Server Directory Application Credential Starts Challenge Login ID: Password: Provide Launch Credentials Application Client Workstation
Login Experience: After Application Server Application Credential Starts Challenge Directory Authenticate Request Secret to NDS Login ID: Password: Provide Launch Credentials Application Receive Secret (ID/Passwd ) Client Workstation
Some Practical Applications ( cont. ) i. Chain : Authorization Broker • Single point of authentication management Areas of Interest • • Security Services WG in OASIS Auth. ML and S 2 ML => SAML Liaison to DSML Common syntax and semantics for – Rights – Privileges • Transformable – XSLT
Today’s Typical Environment Intranet xxx – B tt Employee Sco Bell. S–yyy 229 8 –z zz Intranet W be Ga Employee –x xx yyy – G t Wa 7366–yyy Security Employee Security Ken. S–xxx Sm ith. K –yy 77 y 48 –z zz Security Web Servers and Applications NT/IIS Solaris/Netscape Linux/Apache
i. Chain Solution One Net Employee Ken. S –xxx Customer Scott. B–xxx Partner G – abe. W xxx Security Infrastructure Web Servers and i. Chain Applications NT/IIS Solaris/Netscape Linux/Apache NDS ® e. Directory ™
Summary: Web Services Directory Look up MUST be access controlled • Some interfaces only available “in house” • Other interfaces only available “to friends and partners” • Other interfaces are public Look up MUST be on • Individual Identity • Assumed Role • Delegated Role Service Descriptions MUST be robust • Hosted Services • Run Time documentation = Compile Time doc + formalized semantics
Summary: Web Services Directory (cont. ) Example Problem - Big Government: • • • Walk in the door, look at the sign One line to get a form (“Am I in the right line? ”) Another line to process/approve the form Another to pay “Sorry, go back, you can’t do that here…” Solution • Access Controls: Can’t go any farther than allowed • Single data source: Go all the way to the 7 th floor only to find out the office is moved - forgot to update the sign • Services that aggregate services: Help desk - they know the sequences of lines and windows.