> From: John Mettraux <[EMAIL PROTECTED]>
> Reply-To: <[email protected]>
> Date: Thu, 6 Dec 2007 21:49:22 +0900
> To: <[email protected]>
> Subject: [openwferu-dev] Re: RESTful API, User Authentication and Delegated
> Authorization for workflows
>
>
>>> From: andreas <[EMAIL PROTECTED]>
>>>
>>> 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.
>
> On Dec 6, 2007 4:03 AM, Pat Cappelaere <[EMAIL PROTECTED]> wrote:
>>
>> It is a true statement that user access is usually bound to a role. You do
>> need to capture the user id (openid) to determine what role that user has on
>> that site and get the access level.
>> In my case, the access can be different throughout the workflow.
>> I.e. The user needs some access level to start the workflow. Workflow
>> executes and tries to access a web service at another site (like task a
>> satellite). The user needs to have access to that site and authorize the
>> workflow to act on his behalf and possibly task the satellite if access is
>> granted on that site for that user.
>> This type of scenario (not unusual) can only be met (AFIK) with a mix of
>> OpendID 2.0 and OAuth.
>
> 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.
When the process executes and accesses a data provider on another site, what
access rights are we talking about now?
It has to be user centric and not process centric. This is core to Identity
2.0.
>
> 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)
Cheers,
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
-~----------~----~----~----~------~----~------~--~---
