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 -~----------~----~----~----~------~----~------~--~---
