Jerry Waldorf's Blog
End to end Demo of SPMLv2 for Salesforce.com
Here is a video of the Gateway in action:
Posted at 02:58AM Aug 23, 2008 by Jerry Waldorf in Sun | Comments[5]
SPMLv2 Gateway Solution for Salesforce.com
We have released a Solution that runs on our SPMLv2 Gateway allowing anyone to provide an SPMLv2 compliant interface to their Salesforce.com service. Now all of your provisioning of users to Salesforce.com can be totally automated through any Identity Management product in the market that supports SPMLv2. This should dramatically reduce the time it takes to implement an automated provisioning solution in your enterprise to the industry leading SaaS vendor Salesforce.com. Give it a spin. You can find details on how to download and deploy it here.
Posted at 12:12AM Aug 23, 2008 by Jerry Waldorf in Sun | Comments[2]
A WSDL file for SPMLv2
The SPMLv2 specification as defined here does not contain a WSDL. For standardization we felt that defining a standard WSDL for SPMLv2 would be a good idea.
Here is the WSDL document that we have defined to describe an SPMLv2 Service. It has a SOAP Binding and includes all of the operations defined in the specification.
This is a description of the main parts of the WSDL.
We first have some basic namespace definitions:
<wsdl:definitions
name="SPML"
targetNamespace="urn:oasis:names:tc:SPML:2:0:wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:oasis:names:tc:SPML:2:0:wsdl"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:spml="urn:oasis:names:tc:SPML:2:0"
xmlns:spmlupdates="urn:oasis:names:tc:SPML:2:0:updates"
xmlns:spmlbulk="urn:oasis:names:tc:SPML:2:0:bulk"
xmlns:spmlsuspend="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:pass="urn:oasis:names:tc:SPML:2:0:password"
xmlns:spmldsml="urn:oasis:names:tc:SPML:2:0:DSML"
xmlns:spmlbatch="urn:oasis:names:tc:SPML:2:0:batch"
xmlns:spmlasync="urn:oasis:names:tc:SPML:2:0:async"
xmlns:spmlsearch="urn:oasis:names:tc:SPML:2:0:search"
xmlns:spmlref="urn:oasis:names:tc:SPML:2:0:reference">
Next we have the types section of the WSDL. Here we just import the all of the XML Schema files that are part of the formal specification.
<wsdl:types>
<xsd:schema targetNamespace="urn:oasis:names:tc:SPML:2:0:wsdl">
<xsd:import schemaLocation="pstc_spmlv2_core.xsd" namespace="urn:oasis:names:tc:SPML:2:0"/>
<xsd:import schemaLocation="pstc_spmlv2_updates.xsd" namespace="urn:oasis:names:tc:SPML:2:0:updates"/>
<xsd:import schemaLocation="pstc_spmlv2_bulk.xsd" namespace="urn:oasis:names:tc:SPML:2:0:bulk"/>
<xsd:import schemaLocation="pstc_spmlv2_suspend.xsd" namespace="urn:oasis:names:tc:SPML:2:0:suspend"/>
<xsd:import schemaLocation="pstc_spmlv2_password.xsd" namespace="urn:oasis:names:tc:SPML:2:0:password"/>
<xsd:import schemaLocation="pstc_spmlv2_dsml.xsd" namespace="urn:oasis:names:tc:SPML:2:0:DSML"/>
<xsd:import schemaLocation="pstc_spmlv2_batch.xsd" namespace="urn:oasis:names:tc:SPML:2:0:batch"/>
<xsd:import schemaLocation="pstc_spmlv2_async.xsd" namespace="urn:oasis:names:tc:SPML:2:0:async"/>
<xsd:import schemaLocation="pstc_spmlv2_search.xsd" namespace="urn:oasis:names:tc:SPML:2:0:search"/>
<xsd:import schemaLocation="pstc_spmlv2_reference.xsd" namespace="urn:oasis:names:tc:SPML:2:0:reference"/>
</xsd:schema>
</wsdl:types>
Now we define messages for each of the operations. The mapping is pretty straightforward. For each Request XML Schema element we make a message part and for each Response XML Schema we make a separate message part. For example here is the message definitions for the addRequest and addResponse.
<wsdl:message name="addRequest">
<wsdl:part name="body" element="spml:addRequest" />
</wsdl:message>
<wsdl:message name="addResponse">
<wsdl:part name="body" element="spml:addResponse" />
</wsdl:message>
Now we have the portType definition. Using the above messages:
<wsdl:portType name="SPML">
<wsdl:operation name="add">
<wsdl:input message="tns:addRequest"/>
<wsdl:output message="tns:addResponse"/>
</wsdl:operation>
...
</wsdl:portType>
Now we create a binding section for the SOAP messages that will be transported over http. We use a document style and create a naming convention for the soapAction based on the namespace and operation name. To keep things simple we use literal encoding.
<wsdl:binding name="SOAP" type="tns:SPML">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="add">
<soap:operation style="document" soapAction="urn:oasis:names:tc:SPML:2:0:req/add" />
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
...
</wsdl:binding>
And finally we have the service definition. Using https to align with the spec around using SSL and client/server certificate authentication.
<wsdl:service name="SPML">
<wsdl:port name="SOAP" binding="tns:SOAP">
<soap:address location="https://host.com/spmlv2soap"/>
</wsdl:port>
</wsdl:service>
Posted at 09:17PM Aug 19, 2008 by Jerry Waldorf in Sun | Comments[3]
SPMLv2 Gateway Solution for JDBC
I have uploaded a simple solution for the Gateway that is a starting point to implement SPMLv2 provisioning into your Java EE applications that use a database to manage their users. You can find out more information about it here.
The solution is a simple servlet that uses JDBC to access the database for managing the users. Below is an overview architecture picture:
Posted at 07:02PM Aug 14, 2008 by Jerry Waldorf in Sun | Comments[2]
Identity Synchronization with SPMLv2
A common use case in the Identity Management universe is the synchronization of identity information between different applications. Sometimes this involves synchronizing information between a Human Resources Application and a Directory for example SAP HR to Microsoft Active Directory. When a new employee is added to the SAP HR Application a new user account needs to be created in the Active Directory. And when that employee's status in the SAP HR Application is changed to terminated the user account needs to be deleted from the Active Directory.
Another use case is the Password Synchronization scenario. If the user changes her password in one Directory we would like her password to be updated in the other applications that she has accounts in. For example, if the user changes her password in Active Directory then we would like her password to also be changed to the same value in the RACF system on z/OS.
There are a number of architectures that can solve these use cases. There are pull based architectures and push based architectures. I will try to go through each of these to describe the different possibilities. In general push based approaches tend to work well when you have few destinations and they are relatively static in number. Pull based approaches tend to work well when you have many subscribers and you don't know about the number of subscribers that will exist as they tend to come and go. Pull based models work very well in the web 2.0 world as demonstrated by the popularity of things link RSS and atom.
For the SAP HR --> Active Directory use case we can use the push model:
In this case our SPMLv2 Gateway will poll the SAP system checking to see if there are any new employees that have been added. It uses the BAPI/JCO calls to do this. If the SPMLv2 Gateway finds a new employee it would invoke the add operation over SPMLv2/HTTP to the Identity Manager which would in turn invoke the SPMLv2 add operation on the SPMLv2 Gateway that would add the new user to Active Directory using the LDAP transport to MS AD.
For the SAP HR --> Active Directory use case we can also use the pull model:
In this case our SPMLv2 Gateway will do the same polling to the SAP system as describe above. It will then store the changes into a local database that is made part of the SPMLv2 Gateway. All of these changes would be stored with a timestamp recording when the change was made. Now on a polling interval specified in the Identity Manager's configuration the IdM Server would call the SPMLv2 updates operation on the SPMLv2 Gateway retrieving all of the updates to employees (additions and modifications) and then make the corresponding add/modify/delete operation over SPMLv2 to the Gateway which would invoke the appropriate operation on the MS AD using LDAP. The same as in the use case above.
For the Active Directory password synchronization use case things are a little more complicated because we need to get the password changes out of Microsoft Active Directory. And because Active Directory does not store the password (it only stores a one way hash of the password) you cannot get access to it over LDAP. You need an agent that runs natively on Windows to capture the Password changes. And the agent must run on all of the domain controllers, so you will need one Gateway and potentially many agents all talking to that one gateway. So unlike the use cases above where you only need a Gateway, in this case you need to have an Agent on each domain controller and one Gateway to receive the information from all of them.
For the AD --> RACF using the push model:
In this use case the password Agent would let the Gateway know via a proprietary protocol (maybe over HTTPS) that a users password is being reset. The Gateway would query Active Directory for any additional information about the user needed and then make an SPMLv2 changePassword call to the Identity Manager which would then in turn invoke the SPMLv2 Gateway with the changepassword operation which would use the TN3270 screen scraper adapter to change the password in the legacy application.
For the AD --> RACF using the pull model:
In this use case the same flow of control would be done from the agent to the gateway. The gateway would store these changes locally in an updates database. All of these changes would be stored with a timestamp recording when the change was made. Now on a polling interval specified in the Identity Manager's configuration the IdM Server would call the SPMLv2 updates operation on the SPMLv2 Gateway retrieving all of the updates to users (additions and modifications as well as password changes) and then make the corresponding add/modify/delete/changePassword operation over SPMLv2 to the Gateway which would invoke the appropriate operation on the RACF system using TN3270. The same as in the use case above.
Posted at 12:20PM Aug 13, 2008 by Jerry Waldorf in Sun | Comments[2]
Identity Management with SPMLv2 == SOA
By employing a Service Oriented Architecture (XML over HTTP) in your enterprise you gain one of the main benefits of sharing or reuse of those services you develop. If you create a service that allows customer information to be looked up in a legacy CRM system, now any application that has the proper authorization can get access to this information providing an environment where new innovative business processes and dashboards can be created in a very rapid way. Providing a very agile and flexible organization built to win.
This same benefit can be had in the Identity space with SPMLv2. The User Management features of legacy applications can be SOA enabled with the SPMLv2 standard (by using the SPMLv2 Gateway or any other SOA technology). This opens up a wide variety of reuse opportunities; Automated provisioning can now be done to this application allowing compliance measures to be met, Role Management initiatives can reuse the service to extract information about users and the entitlements they have in that application, Compliance Reports can be generated through reuse of the service to find information about what user has access to what applications, ... Once the user management functionality of the application is SOA enabled the opportunities are unlimited.
Posted at 01:15PM Aug 12, 2008 by Jerry Waldorf in Sun | Comments[2]
OpenPTK, Identity Manager, and Keychain (the Open Source SPMLv2 Gateway)
OpenPTK, Sun's Identity Manager, and Keychain the SPMLv2 Gateway are all non overlapping components that can work together to help build a standards based Identity Provisioning Solution. The OpenPTK is made up of libraries and example code that shows how to invoke an Identity Management System using SPML. The SPML Gateway helps integrate any SPML compliant Identity Management solution to legacy applications. So these two open source projects (OpenPTK and SPML Gateway) are compatible and complementary to each other. And help Sun's Identity Management product fit in with the open protocol of SPML.
Posted at 11:24AM Aug 07, 2008 by Jerry Waldorf in Sun | Comments[5]
Keychain: The Open Source SPMLv2 Gateway
Keychain is an open source SPMLv2 Gateway following the design pattern described in an earlier post. It is intended to provide connectivity to legacy applications that do not yet have native support for SPMLv2.
Here is a short presentation describing the background for the project
Posted at 03:32PM Aug 06, 2008 by Jerry Waldorf in Sun | Comments[2]