John, I believe that Kisha needs to consider authorization. It will allow a user to remotely start a process-definition. This needs to be done securely and within the realm of access of that user and within the granted access of the consumer by that user.
Regarding the second question, A process-definition runs with the privileges of the user that started it. Let's take an example: A workflow can access a web service on another site. How do you tell that web service who you are acting on behalf of and the privileges (granted to the user and privileges that the user granted to the workflow)? The remote transaction could incur a cost for that user. Is that user ok with that? Does that user have the same level of privileges at that remote site? Using name/password basic authentication is not secure (too easy to get access to the password in base-64 encoded) 1 Authentication is very easy with OpenID and secure enough (not 100% but...) 1a Whitelisting is important. You only accept credentials from trusted Openid providers. 1b user/pass in local db... Hummm! You could but why bother when you could have SSO 1c Identity 2.0 absolutely! 2 authorization is kind of at the core of workflows so you need to deal with it somehow. 2a This is defined in the access realm of Oauth and maps to the resources so it is built-in 3. That is an option for later but extremely easy to implement (one table) I agree no to have much features in Kisha but it is not really that bad. Densha needs to support OpenID (Trivial) Kisha needs to watch digital signatures in the authentication headers (Oauth) And eventually those 2 packages need to be integrated for full delegation of authority. As you say, it is Open Source. The beauty is that you can leverage a large community of developers to get there. You are not alone. Cheers, Pat. > From: John Mettraux <[EMAIL PROTECTED]> > Reply-To: <[email protected]> > Date: Wed, 5 Dec 2007 22:35:00 +0900 > To: <[email protected]> > Subject: [openwferu-dev] Re: RESTful API, User Authentication and Delegated > Authorization for workflows > > > Hi List, > > On Dec 5, 2007 11:53 AM, cappelaere <[EMAIL PROTECTED]> wrote: >> >> As a RESTful API is being defined for OpenWFE, there are several >> issues to address: >> 1. It needs to follow AtomPub standard and its discovery capability >> (service document) > > Yes. AtomPub is very important. > > >> 2. it needs to address Identity 2.0. Users need to be authenticated >> (within a federated environment) and users need to be able to delegate >> their authorities to workflows so they can act on their behalf (access >> other web services on other sites for example) > > As of this writing, Kisha, the RESTful envelope for Rufus (OpenWFEru) > I develop at http://openwferu.rubyforge.org/svn/trunk/kisha/ only > supports whitelisting (localhost) for authentication and has no > authorization scheme in place. > >> Here is the result of our current research >> http://blog.geobliki.com/articles/2007/11/25/workflows-restful-ogc-services-a >> nd-identity-2-0 >> >> 1. OpenID 2.0 for user authentication. This would be really easy to >> add to Densha using JanRain libraries. >> 2. Delegation of Authority can be done with OAuth 1.0 >> 3. Access Control to restrict user access to specific resources. >> some people may use LDAP or ActiveRBAC or whatever else... >> >> The workflow instance (or process) is the consumer trying to access >> the data provider. I suppose that we can consider the engine being >> the consumer. This will require the engine to register at various >> sites and exchange a secret. >> >> Workflow instance needs to carry along the user openid (or identity >> url) > > Really ? I have the impression that some processes would have to rely > on different credentials for some participants / activitites. > But why not, back to the basics, a program is run with the privileges > of the user that started it (userspace). > > >> It is likely that a specific participant would be designed to handle >> that interface and deal with this. >> >> This works fairly well with AtomPub. The engine is itself a service >> so users would need the capability to create/read/update/delelete >> resources securely. > > I see these things in this order : > > 1). authentication > 1a). whitelisting > 1b). user / pass in local db > 1c). identity 2.0 > 2). authorization > 2a). who has the right to do what on which resource > =-=-=-=-= > 3). delegation of authority > > Do you see 3 as an extension of 2 ? My gut feeling is that it > shouldn't be part of Kisha as a piece of code, but it could be > materialized as a "best practice". Somehow, I have the impression that > an authorization token is yet another piece of info that can be put in > the payload of a workitem. > > >> I would love to see a concordance in that area from a greater >> community for interoeprability. > > I'd love to to have not too much features go into Kisha, in the end, > I'll be alone at maintaining, this is open source, people come and go. > Fortunately, it's Ruby and Rails, it's easy to keep the system open > and extensible. > > > Cheers, > > -- > 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 -~----------~----~----~----~------~----~------~--~---
