Jerry Waldorf's Blog
Roles, Entitlements, and User Attributes
What constitutes a users "role" in a particular application. Often it is a collection of many attributes about the user. For example, a user of a helpdesk application could have what would traditionally be thought of as a role of an administrator, end user, or agent. In addition the agent could have a "language" attribute that defines what languages that user speaks. If the user speaks French, English, and German. Then this attribute would reflect that. And the types of things that the user does in the application would change based on this attribute. For example, the user would be able to answer questions from customers that speak French. This attribute effects the behavior of the application just as much as the fact that the user is administrator or agent. Another example would be the timezone that a user is in would determine how calls are routed to that individual. This would be another attribute of the user that would effect the behavior of the application. In summary, many of the attributes of the user effect the applications behavior. Some can be easily classified as user roles. Others are a bit more fuzzy.
Posted at 09:56PM Jan 14, 2009 by Jerry Waldorf in Sun | Comments[5]
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[4]
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]
Adapters, Gateways, Agents, and Native
In the pursuit of SOA in existing enterprises, developers will undoubtedly come across legacy application services that they would like to include. These services are hidden from the other applications behind legacy proprietary protocols. The legacy protocols make it difficult to include the "services" in the new business processes and composite services that the nimble SOA environment enables because they require proprietary client libraries and other heavy encumbrances.
We need some way to bring these legacy application services into the SOA environment. There are a number of ways to get this to happen:
Adapters -- allow the Integration Platform/BPMS to connect to these legacy applications by plugging in directly to the platform an adapter that can speak the proprietary protocol to the legacy application
Gateways -- create a separate Gateway that speaks standard Web Services over HTTP on one side and the proprietary protocol on the other, basically a proxy for the legacy service.
Agent -- a plug in that runs in the legacy application, providing a local translation of the legacy service to a modern protocol of Web Services over HTTP.
Native -- upgrade the legacy application to the latest version that has a native way to expose the legacy application's services as Web Services over HTTP.
A graphic of the above:
So which is the best approach. They each have their pros and cons.
Adapters -- Adapters plug directly into the Integration Platform/BPMS which makes them easier to deploy and manage. But they lock the Business Processes to a new proprietary platform. If a new BPMS system is desired to replace an existing one, all of the connectivity is locked into the existing BPMS making it hard to replace. We have just moved the problem around without solving it.
Gateways -- This approach has the downside of introducing another moving part. An additional process to keep track of. The benefit is that it allows the BPMS to be decoupled from the connectivity. Thus when the application eventually supports native Web Services over HTTP the Gateway can just be dropped without changing the Business Processes. Also if a new BPMS platform is desired to replace the existing one it can easily be done. Another benefit is that the Gateway exposes this legacy application service to not only this BPMS platform but any other consumer that can be created in the enterprise. Another benefit is that the traffic between the BPMS and the Gateway can be monitored and managed from the large collection of HTTP intermediaries out there.
Agent -- a plug in has many of the benefits of a Gateway, but has the down side of being hard to maintain because they often need to use non public APIS. The Gateway uses proprietary protocols, but supported ones. An agent often needs to use local non public APIs that may change from release to release. Also they have the downside of needing to be installed into the legacy application, potentially breaking existing functionality in the legacy application and requiring special administrator supervision that a Gateway does not require.
Native -- for obvious reasons native support of Web Services over HTTP is the best option, but often times upgrading to newer versions of the legacy application is not possible right away, although recommended in the long term.
So what is the best approach. If possible move to Native support. When this cannot be done, go with a Gateway. It provides the best practical migration strategy to get to SOA without locking you into a another proprietary BPMS solution.
Posted at 10:43PM Jun 02, 2008 by Jerry Waldorf in Sun | Comments[2]
SOA, REST, WADL, and WSDL
There seems to be much debate about REST being better than SOA. And that SOAP is too complicated. And that WSDL requires SOAP and therefore WSDL is too complicated. Developers should be using REST and not SOA. I think that when it really comes down to it there are really just three things that developers should worry about. The first is using HTTP as a way to transfer data between two applications.
We have seen that when a client and server need to interact, the best way to do this is over TCP/IP, using some standard wire protocol. Using a closed system like RMI or SAP's RFC or JDBC for databases requires an API library to be used by the client to talk to the server. This leads to forcing the client and server to use a particular programming language. And sometimes as constrained as a specific version of a specific programming language. Using HTTP as the protocol between the two allows for decoupling such that any language can be used on either side. And because HTTP is the language of the web, the interaction can pass through all types of networks and their firewalls successfully.
Now the next thing to worry about is the description of the valid interaction between the client and the server over HTTP. You can use a non formal description of what the interaction is. But this often leads to ambiguity. A better way to deal with the description is with a formal spec such that there can be no ambiguity. An additional benefit is that you can use tooling in your target language to help you implement the client or server, because the tooling can read the formal metadata on the interaction and create the corresponding consuming or provisioning code to help you get started. At this point there are two standard ways to describe this interaction, WADL and WSDL. As you can see from the picture below there are many potential interactions possible with HTTP. WADL can describe many of them but not all. And WSDL can describe even fewer potential interactions. So the short of it is that if you are doing basic request/reply http interaction and are sending basic XML data back and forth WSDL is a perfectly reasonable metadata language to describe this interaction. You can use either HTTP binding or SOAP binding. If you like the simplicity of basic HTTP interaction without SOAP just use the HTTP binding aspects of WSDL and you will have a simple interaction that is formally described such that tooling can help you on the client or server side.
Are WSDL and REST in conflict with each other. I think the answer is no. WSDL can describe a subset of things that you can do in REST (aka HTTP interactions). And if your current project is implementing a basic POST interaction with XML data being passed back and forth, WSDL is a reasonable way to describe this.
Posted at 05:11PM May 30, 2008 by Jerry Waldorf in Sun | Comments[4]
Using JNI from a web start application
I have been experimenting around with trying to get a windows dll embedded into a jnlp web start jar file. Here is the result App
You can find the code here.
Some interesting things about this. It was very simple to add the dll to the jnlp file:
Posted at 01:24AM Nov 08, 2007 by Jerry Waldorf in Sun | Comments[2]
Service Enabling of Legacy Applications
Many of today's legacy application platforms have support for provisioning their underlying functionality as services available over HTTP. Some examples of this capabilities can be seen in SAP. Where in the latest version of SAP RFC and BAPI "services" can be exposed as HTTP/SOAP based Web Services. The same is true for CICS, IMS, HL7, LDAP, SWIFT, ...
As you can see many of the application platforms are moving towards exposing there functionality as services over SOAP/HTTP. This is a great indication of how SOA is real and the future of how enterprises will implement integration. Using languages like WS-BPEL, Java with JAX-WS, and any other languages that natively support WSDL and SOAP/HTTP, developers can create new composite applications out of these existing services in the enterprise.
So the future looks bright. But what is a developer to do today when they have yet to upgrade to the latest version of the platform or the vendor has announced plans to support natively SOAP/HTTP services but has yet to deliver. What is needed is an adapter. And it is key that the adapter that is used be as close to what the future interface to the application will look like as possible. The adapter should present to the developer something that looks like SOAP/HTTP and the WSDL that will be available for that application in the future. That way when they upgrade to the latest version of the application platform, the adapter can be thrown away and the BPEL, Java code or ... can remain unchanged and just work against the application natively through its WSDL and SOAP/HTTP support.
One place you can find such future proof adapters is in Open ESB. You can find a wide verity of adapters to older versions of legacy application platforms that have WSDL that look like what the latest (and/or future) versions of it look like.
Posted at 12:25PM Aug 29, 2007 by Jerry Waldorf in Sun | Comments[2]