Hi John, Hi Pat, > No need to develop anything new!!!!! The OpenID and Oauth teams have done > some remarkable work. I have already implemented it in GeoBPMS (a > simplified version of it using pre-approved transactions)
It would be nice to use the work of the OpenID and Oauth teams. Especially the decentral and federated approach is very interessted. But I have also some problems to see how this approach works in a business application scope. User centric identity management is easy to understand in the discussed examples (multible accounts for different web sites. In this scenario the identity is the most important aspect th access my own resources. In a business process as a user I'm not the only one which have access to a special resource, like a document or a process instance. It is a normal case that other users can have some access rights to the same resource - instances (all user which have the same (process) role). I'm interessted in but not very familar with OpenID and Oauth and so I don't know in which way the role aspect will be resolved using a user centric identity management approach. Somewhere should be defined which set of OpenID's (representing users) have which access rights to process instances or to other resources. For me a role describe the following: - a role is related to one or more specific activities in a business (or communication) process independent from the aspect if it is implemented on a bpm base. - a role describe the behavior of a process participant - the behavior is related to the performed activities which are related to specific resources - the access to, the creation of or the modification of resources depend on the permission which a user with a defined role (or roles) have Is there a way to transform this to a plain user centric approach ??? Best regards Andreas On 6 Dez., 14:35, "John Mettraux" <[EMAIL PROTECTED]> wrote: > Hi, > > On Dec 6, 2007 10:13 PM, Pat Cappelaere <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Andreas, hi Pat, > > > > I have the impression that Andreas is meaning "a process role" like in > > > "process user", but maybe I'm wrong. > > > Andreas will have to tell us. Users are still in control and accountable > > for workflows acting on their behalf at the end of the day. A User-centric > > architecture is key in my mind. > > > > * Authentication > > > > I was referring to "whitelisting" as restful process/workflow engine > > > trusts host X. It may be practical for limited installs (think about > > > some Rails / MySQL connection). > > > This is actually how Oauth 1.0 works. The Consumer (workflow engine) needs > > to register to the Data Provider and exchange a key and secret in a tbd > > manner to establish the trusted realtionship. > > > > The next step user/pass is a must-have IMO. I don't know enough about > > > OpenID, but I can easily imagine environments where it cannot be used, > > > and I'm sure that some deployments of Kisha will want to go with some > > > unique user (root/root). > > > Well. I think that the only requirement for Kisha would be to pass a user > > identification of sort. It could be an openid, a token or a name... > > > > * Authorization > > > > About authorization, until now I dealt with "user A has the right to > > > launch process P1 and P2" and "user A can read workitems in store S1 > > > and read/write those in store S2". The process itself executed, well > > > with the process engine identity... > > > What you are saying is that user A has access to some resources on that > > machine (P1 and P2). This is a local access control issue. There are many > > ways to deal with that in a generic manner. > > OK, this is my task and I will implement that. > > > When the process executes and accesses a data provider on another site, what > > access rights are we talking about now? > > For a core Kisha implementation, there is no "data provider on another > site", we have to keep things simple. If we build something that > requires an OpenID account and some OAuth server/mecha/whatever, we > will scare away people who don't need it / could implement it by > themselves. > > I want it to walk before it runs. (bad choice of words). > > > It has to be user centric and not process centric. This is core to Identity > > 2.0. > > I understand that for GeoBPMS but what about Kisha and prospective users ? > > > > I think that I have to implement a core Kisha before adding Identity > > > 2.0 to it. Getting back to that work right now. > > > No need to develop anything new!!!!! The OpenID and Oauth teams have done > > some remarkable work. I have already implemented it in GeoBPMS (a > > simplified version of it using pre-approved transactions) > > But Kisha, in its first incarnation/iteration is just a resource, POST > /process, GET /workitem/x, PUT /workitem/y, there are currently no > participant that interact with external resources, what are they, how > could I chose them in advance for my users ? > > GeoBPMS != Kisha > > If there is interaction with other resources, the case 1 user 1 set of > credential is OK, but what happens when 1 process has to interact with > a set of resources where the credentials are different. > > I don't intend to develop anything new if possible, but I want to > provide an engine, not a car, despite the name Kisha. > > -- > John Mettraux -///- http://jmettraux.openwfe.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-dev?hl=en -~----------~----~----~----~------~----~------~--~---
