Web ServicesDirectories

W3C Web Services WS 4/11/01

Scott Isaacsonsisaacson@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

Without a Directory

With a Directory

Standalone OS Network

= Application

= Node

Registry 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

Proposal for DSML 2.0 based on DirXML research

URL for view and download: http://www.novell.com/products/nds/dirxml/dirxmldtddocs.zip

DirXML is a tools for synchronizing directory information between directories that have

• Different schemas• Different administrative tools sets• Different access protocols (even non-LDAP!)

DirXML Example:

PayrollAccounting

Sales

HR Marketing

Partner Database

Legacy Database

Enterpirse Directory

DirXML

Subscriber Channel

Publisher Channel1. Name Change into HR

2. Driver publishes event

3. DirXML syncs all directories

4. Other sources of data modificationsNote: File system, Security, etc.

rights all remain intact on moves

What is the proposal?

A working DTD that defines document structure for:• Commands• Events

Rules (Optional - out of scope?)• Schema Mapping (User vs inetOrgPerson)• 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 | 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="Users\Julia"

dest-dn="cn=Julia,o=Users"

event-id="0">

<add-attr 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="Users\Julia">JuliaGulia1</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 <input> are not usually interesting except to driver writers.

<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

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 DirXML 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 | 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 | teleNumber | 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 base64-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

Example <value> elements:

• "string"<value type="string">Fred</value>

• "octet"<value type="octet">RM8FFyP21kirzwqLjr+Q6g==</value>

• "structured"<value type="structured">

<component name="protectedName">[All Attributes Rights]</component>

<component name="trustee" association-ref="cn=b,o=n">\TREE\O\Admin</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="Users\Julia" event-id="0">

<association>JG0U812</association>

<add-attr 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="Users\Julia" event-id="0">

<association>JG0U812</association>

<modify-attr 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="Users\JImbruglia"

old-src-dn="Users\Julia" event-id="0">

<association>JG0U812</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="Admins\JImbruglia"

old-src-dn="Users\JImbruglia"

event-id="0">

<association>JG0U812</association>

<parent src-dn="Admins">

<association>Admins</association>

</parent>

</move>

<query> Content

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 "\TREE\Novell" 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="\TREE\Novell" scope="subtree">

<search-class class-name="User"/>

<search-attr 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 attr-name="Surname"/>

<read-attr attr-name="CN"/>

<read-attr attr-name="Given Name"/>

<read-attr 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

attr-name CDATA #REQUIRED>

<instance> Content

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="\Users\Samuel">

<association>1012</association>

<attr attr-name="Surname">

<value>Jones</value>

</attr>

<attr attr-name="CN">

<value>Samuel</value>

</attr>

<attr attr-name="Given Name">

<value>Samuel</value>

</attr>

<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="Admins\JImbruglia" event-id="0">

<association>JG0U812</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)

ApplicationApplicationServerServer DirectoryDirectory

ClientClientWorkstationWorkstation

Launch Application

Credential

Challenge

Provide Credentials

Application Starts

Login ID:

Password:

Login Experience: Before

ApplicationApplicationServerServer DirectoryDirectory

ClientClientWorkstationWorkstation

Launch Application

Credential

Challenge

Provide Credentials

Application Starts Authenticat

e to NDSRequest Secret

Receive Secret

(ID/Passwd)

Login ID:

Password:

Login Experience: After

Some Practical Applications (cont.)

iChain: Authorization Broker • Single point of authentication management

Areas of Interest• Security Services WG in OASIS• AuthML and S2ML => SAML • Liaison to DSML• Common syntax and semantics for

– Rights– Privileges

• Transformable– XSLT

Today’s Typical Environment

NT/IIS

Solaris/Netscape

Linux/Apache

Web Servers and Applications

Secu

rity

Secu

rity

Secu

rity

KenS–xxxSmithK–yyy7748–zzz

BellS–yyy

7366–yyy

WatG–

yyyGabeW–

xxx

ScottB–

xxx2298–zzz

Employee

Intranet

Employee

Intranet

Employee

Intranet

iChain Solution

NT/IIS

Solaris/Netscape

Linux/Apache

Web Servers and Applications

Secu

rity

In

frastr

uctu

re

Employee

One Net

Customer

Partner

iChain

KenS–xxx

ScottB–xxx

GabeW–xxx

NDS® eDirectory™

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