Web Services Directories W 3 C Web Services

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> <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 <input> element include: • • • <add> <modify> <delete> <rename> <move> <query> • Other allowed children of except to driver writers. <input> are not usually interesting

<output> Responses Events and commands that can be children of an <output> element include: • <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> (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 Ken. S–xxx Sm ith. K –yy 77 y 48 –z zz Intranet xx Employee Sco Bell. S–yyy 229 8–z zz Intranet W be Ga Employee Security –x tt. B xx –x yy –y at. G W 7366–yyy Security Employee 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 i. Chain Web Servers and 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.