Hi All,
One of the problems I've experienced in WSO2 Identity Server at the moment
is the ability to design/configure a orchestration process for outbound
provisioning.
The current provisioning bridge capability we have, is limited to bridging
calls from client to target applications in a one-to-one fashion. For
example, a user creation is bridged to a user creation, a user update is
bridged to a user update, etc.
However in most practical scenarios this is not enough. For example, in a
scenario as follows we need to orchestrate calls between multiple endpoints
before we can respond back the caller.
1. There is IS and the target application.
2. Accounts and entitlements are managed through SCIM in IS and synced with
the target applications also through SCIM.
3. Let's say I need to update the manager attribute of a user.
Current value: CN=OldManager,OU=SomeOU,DC=SomeDomain,DC=local
New value: CN=NewManager,OU=SomeOU,DC=SomeDomain,DC=local
4. I send a user PATCH request to IS with the new manager value.
5. Following is the service orchestration I need to do
A. Update the local account's manager attribute with the new DN of the
manager
B. Query the new manager's email or windows principal (upn) using the
CN attribute value
C. Once I get the email or windows principal I will query the target
application and get the SCIM ID in the target application for the manager
D. I will then update the user account in the target application (this
is done within the SCIM outbound connector, but also contains two calls,
first to retrieve the remote SCIM ID and then do a PATCH on that remote
account)
E. Once the provisioning is complete I would like to send an email to
the user who initiated the request.
Now using the current provisioning framework capabilities we have we cannot
do this kind of orchestration without writing Java extensions. However, as
usual writing code is not a good solution, as there will be overhead in
maintaining it, updating the orchestration, introducing a new target
application, etc.
So there are two potential solutions I see are as follows:
*Solution 1*
Introduce ESB in the architecture to handle the orchestration of services.
Expose a one-to-one endpoint of inbound provisioning service in ESB, to
delegate all inbound provisioning requests. In the mediation layer, ESB
will orchestrate the outbound provisioning by calling the outbound
provisioning service in IS and other services exposed to get business
specific entitlements, and finally return the result to IS. I don't think
we have outbound provisioning as a service currently, but can expose one.
If we go down this path we can ship this ESB provisioning connector as a
standard provisioning connector in IS or in the Store.
*Solution 2*
Have a BPMN process with service tasks that proxies/wraps the outbound
provisioning SPIs and expose it as a custom construct to BPMN. Using BPMN
editor in developer studio we can do the orchestration of services.
I like the BPMN integration more because, though the example I have
explained is neither asynchronous, nor long running nor have any
persistence, we can extend the example to a more generic problem of
orchestration and workflows, that will be have asynchronous long running
processes, that may need persistence and may even need user tasks. Also
BPMN components are more light weight that we can install the minimal
runtime within IS and ship as well. In that case the service tasks will
just do Java calls to the outbound provisioning SPIs. ESB is a product with
much broader integration capabilities that may not be relevant to IS.
To me option 1 is a good immediate solution for this problem for existing
deployments without too many changes to the existing products. However in
the long term I feel option 2 is a better solution because I can already
see that we have related requirements in the horizon.
Others: Thoughts? What are your opinions on the two options?
Thanks & Regards,
Johann.
--
*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware
Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
