Saturday, February 07, 2009
Federated Provisioning
Ian Glazer and Nishant Kaushik discuss federated provisioning and provide some high-level scenarios that are somewhat incomplete...
Nishant's example assumes that just-in-time provisioning is about an SP accepting a SAML-based authentication and creating an SPML message. I would argue that there may be multiple business scenarios where you may need something more richer than SPML where federated identity products should also know how to invoke BPEL processes.
If we did such a thing in the insurance vertical, an incoming request isn't just about provisioning access to the system. We may need to kick off a business process where we may need to file paperwork with a state insurance department to appoint that agent in the state they reside, we may need to kick off license checks and even schedule CRM-style a followup call with that person to onboard them.
So, an incoming request may provision a user but will they be effectively provisioned? What happens if just passing attributes aren't enough and I need something more rich like XACML? How does this get mapped into SPML in his scenario? For example, if I provision an insurance agent, I might want to know that he can sell commercial insurance in texas, personal insurance in georgia and life insurance in Oklahoma, Kansas and California. I may want to also understand the structure of his organization so that I can show him commissions of his team but not of others within his organization. Note that this is more than just a discussion about roles.
Anyway, if anyone has thoughts at a deeper level, please share as I think the community would benefit from the insight...
| | View blog reactionsNishant's example assumes that just-in-time provisioning is about an SP accepting a SAML-based authentication and creating an SPML message. I would argue that there may be multiple business scenarios where you may need something more richer than SPML where federated identity products should also know how to invoke BPEL processes.
If we did such a thing in the insurance vertical, an incoming request isn't just about provisioning access to the system. We may need to kick off a business process where we may need to file paperwork with a state insurance department to appoint that agent in the state they reside, we may need to kick off license checks and even schedule CRM-style a followup call with that person to onboard them.
So, an incoming request may provision a user but will they be effectively provisioned? What happens if just passing attributes aren't enough and I need something more rich like XACML? How does this get mapped into SPML in his scenario? For example, if I provision an insurance agent, I might want to know that he can sell commercial insurance in texas, personal insurance in georgia and life insurance in Oklahoma, Kansas and California. I may want to also understand the structure of his organization so that I can show him commissions of his team but not of others within his organization. Note that this is more than just a discussion about roles.
Anyway, if anyone has thoughts at a deeper level, please share as I think the community would benefit from the insight...
