Configuring Identity Manager 2 for SOAP

David Holbrook

IDM Engineer dwholbrook@novell.com

Novell, Inc.

Steve Trottier

IDM Engineer strottier@novell.com

Novell, Inc.

Agenda

The vision

Terminology introduction

SOAP Driver demo

Detailed information

System requirements

Q & A

The vision

Vision for the SOAP Driver

Provisioning driver that connects with

HTTP-enabled applications

SOAP-enabled applications

Web services

Flexible and extensible architecture

IDM Driver 1.0 for SOAP

Generic driver with sample configurations

Not oriented to a specific application

Shim provides HTTP(S) connection to web applications

Policies build application-specific messages

Optionally data can be specified in SOAP messages

Customizable to provide method-specific information

Extensible to allow business rules to be implemented

Shim supports Java pre- and post-processors for more complex operations

Sample SOAP configurations are DSML and SPML

Terminology introduction

HTTP

HyperText Transport Protocol

A protocol used to request and transmit data over the Internet or other computer network.

A "stateless" request/response system. The connection is usually maintained only for the immediate request.

The client establishes a TCP connection with the server and sends it a request, the server sends back its response.

Works well with Internet infrastructure, in particular firewalls.

SOAP

Simple Object Access Protocol

A protocol for exchanging messages

Defines the message exchange, not the content

A message-based protocol based on XML

SOAP documents are organized into:

an envelope (the root XML node)

header - provides context knowledge

body - method-specific information

Web services

Simple web services

provide basic "request/response" functionality

provide simple HTTPS/SSL based security

are developed with primary Internet standards

Web services

Web Services	Description	Driver

UDDI	Discovery	Not used

WSDL	Description

SOAP	Remote Service Call	Optional

HTTP	Transport Application	Required

Protocol

TCP/IP	Transport Protocol	Required

Protocol suite

Description	Protocol	Implemented in

Service-Oriented Protocol	SPML, DSML, etc.	Policy

Messaging	SOAP	Policy

Data Encoding	XML	Policy

Network Protocol	HTTP(S)	Shim

SOAP Driver demo

Detailed information

Sample configurations

The driver comes with two sample SOAP configurations

SPML - Service Provisioning Markup Language

An XML-based framework for exchanging user, resource and service provisioning information.

DSML – Directory Services Markup Language

A means of representing directory structural information and directory operations as an XML document.

SPML

Service Provisioning Markup Language

Standard approved by the Organization for the Advancement of Structured Information Standards (OASIS)

SPML version 1.0

Request/Response model

Small number of operations – add, modify, delete, search

Open Content Model – XML document can have additional child elements and attributes not declared in SPML

Binds with SOAP 1.1 using HTTP(S)/1.1 as the transport

SPML sample configuration

IDM2 SPML Import File

Provides generic SPML functionality

Does not pair with a specific SPML application

Provides XDS to SPML conversion in policies

Handles Users, Groups and Organizational Units

Supports string, structured and Distinguished Name (DN) attribute types

SPML sample configuration (cont)

IDM2 SPML Import File

Handles single (non-batch) operations

Supports password set operation

Subscriber channel uses the application-returned Identifier value for the association key

Publisher channel uses the DN for the association key and returns the association key as the Identifier value

DSML

Directory Services Markup Language

Standard approved by the Organization for the Advancement of Structured Information Standards (OASIS)

DSML version 2 (DSMLv2)

A means of representing directory structural information and directory operations as an XML document

Expresses LDAP directory requests and responses in XML

Allows XML-based applications to leverage profile and resource information from a directory

Binds with SOAP 1.1 using HTTP(S)/1.1 as the transport

DSML sample configuration

IDM2 DSML Import File

Shows simple DSML functionality

Pairs with a eDirectory™ DSML implementation

Provides XDS to DSML conversion in policies

Handles Users, Groups and Organizational Units

Supports string, structured and Distinguished Name (DN) attribute types

DSML sample configuration (Cont)

IDM2 DSML Import File

Supports password set operation

Subscriber channel uses the destination DN for the association key

Publisher channel uses the application-provided DN for the association key

Driver shim

Generic shim

Does not interpret the data being passed through it

Just a big data pipe

Data to/from engine must be XML

Data to/from application can be anything

Provides for customer-written Java extensions to handle, interpret, or modify data

Provides for customization of HTTP Request-Header fields

Driver parameters

Driver Settings

Optionally adds or removes XDS required XML elements, <nds>, <input> and <output>

Provides for HTTPS support

Driver parameters

Subscriber Settings

URL of remote server

Authentication ID and Password for remote server

Basic HTTP Request-Header fields

Customizable HTTP Request-Header fields

Key	Value

Authorization	Basic

Content-Type	text/xml; charset=utf-8

SOAPAction	#batchRequest

Driver parameters

Publisher Settings

IP address and port where driver listens for incoming requests

Authentication ID and password required by requester

Driver Heartbeat

Publisher Settings

Java extensions

Allow shim functionality to be extended

Eleven points where functionality can be extended

Four in the subscriber channel

Four in the publisher channel

Two to specify the transport

HTTP is the default but can be replaced

One to report the application schema

Are written in Java using supplied interfaces

Used to operate on data

Must be used to convert non-XML data to XML data

Java extensions diagram

Subscriber Shim

DirXML Policy and Engine

Application

Publisher Shim

Convert XML to/from bytes. Remove/restore operation-data.

XML

XML

XML

XML

Bytes

Bytes

Bytes

Bytes

Convert bytes to/from XML

HTTP Request (POST)

HTTP Response

HTTP Request (POST)

HTTP Response

Publisher Transport

Subscriber Transport

Connecting operations and responses

<operation-data>

Is used to supply information on an operation that is needed by the policy that handles the result of that operation.

Content can be any well-formed XML

Passwords

Password Policies

Initial password

Password set

Policies

Application specific work is done in policies

Output Transformation Policies

Converts XDS to SOAP and SPML/DSML

Written in XSLT

Input Transformation Policies

Converts SOAP and SPML/DSML to XDS

Written in XSLT

Business rules can be implemented in all policies

System requirements

IDM Driver 1.0 for SOAP

System Requirements

Server operating system platforms

NetWare® 6 or 6.5 with the latest Support Pack

Windows NT*, 2000, or 2003 with the latest Service Patch

Linux Red Hat* AS or ES 2.1, or AS 3.0

SUSE LINUX Enterprise Server 8 or 9 (including SP1)

Solaris 8 or 9

AIX 5.2L

IDM Driver 1.0 for SOAP

System Requirements

eDirectory

Novell eDirectory 8.6.2 or 8.7.3 with the latest Support Pack

Identity Manager

Novell Nsure® Identity Manager 2.0.1 or higher

Web-based Administration

Novell iManager 2.0.2 or higher

IDM Driver 1.0 for SOAP

Release Status

Expected availability is May 2005

Questions & answers

The communications protocol used to connect to servers on the Web. Its primary function is to establish a connection with a Web server and transmit HTML pages to the client browser or any other files required by an HTTP application. Addresses of Web sites begin with an http:// prefix; however, Web browsers typically default to the HTTP protocol. For example, typing www.yahoo.com is the same as typing http://www.yahoo.com.

HTTP is a "stateless" request/response system. The connection is maintained between client and server only for the immediate request, and the connection is closed. After the HTTP client establishes a TCP connection with the server and sends it a request command, the server sends back its response and closes the connection (see cookie).

Version 1.0 of HTTP caused considerable overhead to a Web download. Each time a graphic on the same page or another page on the same site was requested, a new protocol connection was established between the browser and the server. In HTTP Version 1.1, a persistent connection allowed multiple downloads with less overhead. It also improved caching and made it easier to create virtual hosts (multiple Web sites on the same server).

SOAP - stands for Simple Object Access Protocol. It is a wire protocol. It is a text-based protocol that uses XML. SOAP is a technology that will be deeply embedded in the future of distributed computing. Coupled with other technologies such as Universal Discovery, Description, and Integration (UDDI) and Web Services Description Language (WSDL), SOAP is set to transform the way business applications communicate over the Web with the notion of Web services.

SOAP documents are neatly organized into an Envelope (the root node), a header section, and a body. The header section is used to encapsulate data that is not tied to a specific method itself, but instead provides context knowledge, such as a transaction ID and security information. The body section contains the method-specific information.

SOAP naturally follows the HTTP request/response message model, which provides SOAP request parameters in an HTTP request and SOAP response parameters in an HTTP response. In fact, SOAP 1.0 specifically designated HTTP as its transport protocol. SOAP 1.1 has loosened up a bit and, although it still works with HTTP, it also works with other protocols such as SMTP.

Web Services consist of a set of messaging protocols, programming standards, and network registration and discovery facilities that expose business functions to authorized parties over the Internet from any Web-connected device.

More simply, a web service is a discrete business process that:

Exposes and describes itself – A web service defines its functionality and attributes so that other applications can understand it, and makes this functionality easily available to other applications.

Allows other services to locate it on the Web – A web service can be registered in a sort of electronic "yellow pages," so that applications can easily locate it.

Can be invoked – Once a web service has been located and examined, the remote application can invoke its service using an Internet standard protocol.

Returns a response – When the service has been provided, the results are passed back to the requesting application again over the same Internet standard protocol.

There are two types of web services - simple and complex. Simple web services provide basic "request/response" functionality, are typically not transactional in nature, and provide simple HTTP-S/SSL based security. They are developed supporting three primary Internet standards - SOAP, WSDL, and UDDI. Complex web services can be characterized as multi-party, long-running business "conversations" that involve sophisticated security, such as non-repudiation and digital signatures, as well as business-to-business collaboration and business process management. They are developed supporting two primary Internet standards - ebXML and RosettaNet.

transaction

An activity or request. Orders, purchases, changes, additions and deletions are typical business transactions stored in the computer. Transactions update one or more master files and serve as both an audit trail and history for future analyses. Ad hoc queries are a type of transaction as well, but are usually just acted upon and not saved.

transaction processing

Updating the appropriate database records as soon as a transaction (order, payment, etc.) is entered into the computer. It may also imply that confirmations are sent at the same time.

Transaction processing systems are the backbone of an organization because they update constantly. At any given moment, someone may need an inventory balance, an account balance or the total current value of a financial portfolio. Also called "online transaction processing" (OLTP), the OLTP market is a demanding one, often requiring 24x7 operation and the most reliable computers and networks.

A manual example of transaction processing would be that every time you purchased an item, you added the amount paid to a running total. Contrast with "batch processing," which means that you save all receipts in a drawer and add them up at the end of the year for taxes.

Web-based applications that dynamically interact with other Web applications using open standards that include XML, UDDI and SOAP. Such applications typically run behind the scenes, one program "talking to" another (server to server).

Web services enable software components to interact with each other around the world. In the past, this has only occasionally been realized within private networks using the industry standard CORBA and Microsoft's DCOM distributed component platforms. However, Web services use XML-based protocols that are lightweight and simpler and thus have a better chance of being widely implemented.

Advantages of web services

·	Web services provide interoperability between various software applications running on various platforms.

·	Web services leverage open standards and protocols. Protocols and data formats are text based where possible, making it easy for developers to see and understand what is going on.

·	By piggybacking on HTTP, web services can work through many common ··firewall security measures without requiring changes to their filtering rules.

Disadvantages of web services

·	Web services standards for features such as ··transactions are currently nonexistent or still in their infancy compared to more mature ··distributed computing open standards such as ··CORBA.

·	Web services suffer from poor ··performance compared to other distributed computing approaches such as ··RMI, ··CORBA, or ··DCOM. This is a common trade-off when choosing text based formats. ··XML explicitly does not count among its design goals either conciseness of encoding or ··efficiency of ··parsing.

·	By piggybacking on HTTP, web services can evade existing ··firewall security measures whose rules are intended to block or audit communication between programs on either side of the firewall.

Reasons for creating web services

The main reason web services are used seems to be that they rely on HTTP over TCP port 80. To understand this, keep in mind that many enterprises have protected themselves (see computer security) by using firewalls that filter and block much Internet traffic for security reasons. In this milieu, typically many (almost all) ports are closed to incoming and outgoing traffic, and the administrators of these firewalls are not eager to open them up. Port 80, however, is always open because it is used for web browsers. Web services tunnel everything through port 80, making the technology very appealing.

Another reason may be that prior to SOAP, there were no really good interfaces to accessing functionality on different computers on a network. Most of them were ad hoc, and few people knew or could handle EDI, RPC, and similar APIs. Web services may have more solid frameworks and would thus be easier to use.

A third reason that web services are useful: They can provide very loose coupling between an application that uses the web service and the web service itself. This should allow either piece to change without negatively affecting the other. This flexibility may become increasingly important as software is built by assembling individual components into a complete application.

The general model adopted by SPML is one of clients performing protocol operations against servers. In this model, a client issues an SPML request describing the operation to be performed at a given service point. The service point is then responsible for performing the necessary operation(s) to constitute the implementation of the requested service. Upon completion of the operation(s), the service point returns to the client an SPML response detailing any results or errors pertinent to that request.

The core operations schema provides a small number of generic operations (Add, Modify, Delete, Search) and an open model for the definition and discovery of that schema as a set of simple name=(multi)value pairs.

The SPML V1.0 XML Schema follows an "Open Content Model". In this model, any SPML element in an XML document can have additional child elements and attributes that are not declared in the core SPML V1.0 schema. In contrast, a "Closed Content Model", would prevent the inclusion of any elements not defined in the SPML core XSD.

This implementation shall adhere to Service Provisioning Markup Language version 1.0.

SPML binds with SOAP 1.1 using HTTP/1.1 and HTTPS/1.1 as the transport

An XML-based framework, being developed by OASIS, for exchanging user, resource and service provisioning information between cooperating organizations.

The goal is to allow organizations to securely and quickly set up user interfaces for Web services and applications, by letting enterprise platforms such as Web portals, application servers, and service centers generate provisioning requests within and across organizations. This can lead to automation of user or system access and entitlement rights to electronic services across diverse IT infrastructures, so that customers are not locked into proprietary solutions.

For example, a supply partner (Company A) goes to its partner's (Company B) supply chain portal and requests access to its inventory data, which is stored in a back-office system. In response, Company B initiates a request using SPML to communicate with SPML-enabled identity management software. After automatically acquiring the appropriate permissions, Company B grants the appropriate access levels to Company A to gain access to the data it needs.

This process takes place without the need for the portal environment to have an intimate understanding of the back-office environment. In other words, it's all automatic. The prototype encompasses all of the provisions of the proposed SPML standard while also leveraging the benefits of the Security Assertion Markup Language (SAML).

The general model adopted by SPML is one of clients performing protocol operations against servers. In this model, a client issues an SPML request describing the operation to be performed at a given service point. The service point is then responsible for performing the necessary operation(s) to constitute the implementation of the requested service. Upon completion of the operation(s), the service point returns to the client an SPML response detailing any results or errors pertinent to that request.

The core operations schema provides a small number of generic operations (Add, Modify, Delete, Search) and an open model for the definition and discovery of that schema as a set of simple name=(multi)value pairs.

The SPML V1.0 XML Schema follows an "Open Content Model". In this model, any SPML element in an XML document can have additional child elements and attributes that are not declared in the core SPML V1.0 schema. In contrast, a "Closed Content Model", would prevent the inclusion of any elements not defined in the SPML core XSD.

This implementation shall adhere to Service Provisioning Markup Language version 1.0.

SPML binds with SOAP 1.1 using HTTP/1.1 and HTTPS/1.1 as the transport

An XML-based framework, being developed by OASIS, for exchanging user, resource and service provisioning information between cooperating organizations.

The goal is to allow organizations to securely and quickly set up user interfaces for Web services and applications, by letting enterprise platforms such as Web portals, application servers, and service centers generate provisioning requests within and across organizations. This can lead to automation of user or system access and entitlement rights to electronic services across diverse IT infrastructures, so that customers are not locked into proprietary solutions.

For example, a supply partner (Company A) goes to its partner's (Company B) supply chain portal and requests access to its inventory data, which is stored in a back-office system. In response, Company B initiates a request using SPML to communicate with SPML-enabled identity management software. After automatically acquiring the appropriate permissions, Company B grants the appropriate access levels to Company A to gain access to the data it needs.

This process takes place without the need for the portal environment to have an intimate understanding of the back-office environment. In other words, it's all automatic. The prototype encompasses all of the provisions of the proposed SPML standard while also leveraging the benefits of the Security Assertion Markup Language (SAML).

The general model adopted by SPML is one of clients performing protocol operations against servers. In this model, a client issues an SPML request describing the operation to be performed at a given service point. The service point is then responsible for performing the necessary operation(s) to constitute the implementation of the requested service. Upon completion of the operation(s), the service point returns to the client an SPML response detailing any results or errors pertinent to that request.

The core operations schema provides a small number of generic operations (Add, Modify, Delete, Search) and an open model for the definition and discovery of that schema as a set of simple name=(multi)value pairs.

The SPML V1.0 XML Schema follows an "Open Content Model". In this model, any SPML element in an XML document can have additional child elements and attributes that are not declared in the core SPML V1.0 schema. In contrast, a "Closed Content Model", would prevent the inclusion of any elements not defined in the SPML core XSD.

This implementation shall adhere to Service Provisioning Markup Language version 1.0.

SPML binds with SOAP 1.1 using HTTP/1.1 and HTTPS/1.1 as the transport

An XML-based framework, being developed by OASIS, for exchanging user, resource and service provisioning information between cooperating organizations.

The goal is to allow organizations to securely and quickly set up user interfaces for Web services and applications, by letting enterprise platforms such as Web portals, application servers, and service centers generate provisioning requests within and across organizations. This can lead to automation of user or system access and entitlement rights to electronic services across diverse IT infrastructures, so that customers are not locked into proprietary solutions.

For example, a supply partner (Company A) goes to its partner's (Company B) supply chain portal and requests access to its inventory data, which is stored in a back-office system. In response, Company B initiates a request using SPML to communicate with SPML-enabled identity management software. After automatically acquiring the appropriate permissions, Company B grants the appropriate access levels to Company A to gain access to the data it needs.

This process takes place without the need for the portal environment to have an intimate understanding of the back-office environment. In other words, it's all automatic. The prototype encompasses all of the provisions of the proposed SPML standard while also leveraging the benefits of the Security Assertion Markup Language (SAML).

The Directory Services Markup Language (DSML) provides a means of representing directory structural information and directory operations as an XML document. The intent of DSML is to allow XML-based enterprise applications to leverage profile and resource information from a directory in their native environment. DSML allows XML and directories to work together and provides a common ground for all XML-based applications to make better use of directories.

The Directory Services Markup Language v1.0 (DSMLv1) provides a means for representing directory structural information as an XML document. DSMLv2 goes further, providing a method for expressing directory queries and updates (and the results of these operations) as XML documents.

This implementation shall adhere to Directory Services Markup Language v2.0.

DSMLv2 binds with SOAP 1.1 using HTTP/1.1 and HTTPS/1.1 as the transport.

The Directory Services Markup Language (DSML) provides a means of representing directory structural information and directory operations as an XML document. The intent of DSML is to allow XML-based enterprise applications to leverage profile and resource information from a directory in their native environment. DSML allows XML and directories to work together and provides a common ground for all XML-based applications to make better use of directories.

The Directory Services Markup Language v1.0 (DSMLv1) provides a means for representing directory structural information as an XML document. DSMLv2 goes further, providing a method for expressing directory queries and updates (and the results of these operations) as XML documents.

This implementation shall adhere to Directory Services Markup Language v2.0.

DSMLv2 binds with SOAP 1.1 using HTTP/1.1 and HTTPS/1.1 as the transport.

The Directory Services Markup Language (DSML) provides a means of representing directory structural information and directory operations as an XML document. The intent of DSML is to allow XML-based enterprise applications to leverage profile and resource information from a directory in their native environment. DSML allows XML and directories to work together and provides a common ground for all XML-based applications to make better use of directories.

The Directory Services Markup Language v1.0 (DSMLv1) provides a means for representing directory structural information as an XML document. DSMLv2 goes further, providing a method for expressing directory queries and updates (and the results of these operations) as XML documents.

This implementation shall adhere to Directory Services Markup Language v2.0.

DSMLv2 binds with SOAP 1.1 using HTTP/1.1 and HTTPS/1.1 as the transport.

BS05 TUT149 - Configuring Identity Manager for SOAP

Brainshare 2005

2003-12-08T12:43:39

David Holbrook