John,
> From: John Mettraux <[EMAIL PROTECTED]> > Reply-To: <[email protected]> > Date: Thu, 6 Dec 2007 22:35:03 +0900 > To: <[email protected]> > Subject: [openwferu-dev] Re: RESTful API, User Authentication and Delegated > Authorization for workflows > > > 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. This is actually application specific and should not really be handled by Kisha, IMHO if you really want to keep it lean. > >> 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). Kisha is actually not a data consumer but a data provider. It provides access to resources in a RESTful manner. Kisha ought not to require openid, I agree. However, it needs to grants access to resources (worflows) in a fairly secure manner using REST. So the consumer in this case is the application that invokes Kisha to gain access to the resources (create a new workflow instance and run it). That consumer needs to have a trusted relationship with Kisha to make it simple. So they could exchange OPTIONALLY a key and secret and use that in the authentication headers as an option/alternative to username/passwords. For some applications, they will have the capability to get access to the oauth token that could be the user id and decide to grant or not access to the resources. When a workflow execute, the engine might become a consumer to another data provider. This is not a Kisha problem per say but a custom participant's problem that know how to handle this. This keeps Kisha lean but scalable for some. >> 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 can't say anything more about this. >>> 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 ? You don't as explained earlier. > GeoBPMS != Kisha I have said that before. GeoBPMS is a custom application on top of OpenWFERu, Densha and Kisha + LDAP, XMPP... > 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. All those use-cases are not new to those protocols. You do not need to reinvent them and trust that those people have done their homework. > I don't intend to develop anything new if possible, but I want to > provide an engine, not a car, despite the name Kisha. Not just you but there is a whole community out there that wants the same thing. Pat. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
