Hi John, Hi list, authentication and authorization are very important aspects of a wide range of web and bpm related applications. I'm also very interessted in checking the new identity 2.0 staff. On the other site identity is only the first step. In b2b applications authorization is a key functionallity. >From my point of view process instances are typical bound to "process roles" not to single users. Single user bound process instances are only a special case. Potentially some problem domains exits where a single user bound process instance is the normal case.
Best regards Andreas On 5 Dez., 14:35, "John Mettraux" <[EMAIL PROTECTED]> wrote: > 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 athttp://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-se... > > > 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 -~----------~----~----~----~------~----~------~--~---
