Workflows, security and delegation of authority to workflows
12 views
Skip to first unread message
cappelaere
Dec 12, 2008, 9:55:34 AM12/12/08
to WfXML
Keith and I have been exchanging emails regarding the OWS-6 scenario
and the security implication to workflows.
I think that it is getting close to the time to start capturing the
issues and converge towards an acceptable architecture for
interoperability so we can get ready for our first TIE.
First of all, do we want to use a private email list to discuss or do
we want to use the wfxml group?
Since WfXML-R spec might refer to RESTful security, this might not be
a bad place but I am opened to other suggestion (could be on the WfMC
board but not everyone is a member...)
Here is a recap to get everyone up to speed.
With OWS-5, we implemented security using OpenID + simplified version
of OAuth with pre-approved transactions. This allowed us to do one
one-time registration and one-time user grant access, then the OAuth
transaction is reduced to a one trip secure transaction.
Keith has suggested to bypass the consumer/provider registration by
using SSL.
Rather than requiring user to pre-approve transaction, Keith has
suggested to follow the OAuth protocol when the workflow is installed
but not executed. Appropriate tokens would be acquired by the
installer guy from the right servers and maintained by the workflow.
When the workflow is run, tokens would be exchanged for access
tokens. Workflow could only run by the installer or a person allowed
by the installer. Service provider would think in any case that the
user is the installer unless we can also add the end-user openid for
auditing purpose.
For OWS-6 we also need to demonstrate temporary trust. For example,
NASA might have to temporary trust the California Fire Fighter OpenID
provider, determine that Joe is a valid firefighter and has the
tasking role as granted by his organization.
Looking forward to hear from you guys.
Thanks again.
Pat.
and the security implication to workflows.
I think that it is getting close to the time to start capturing the
issues and converge towards an acceptable architecture for
interoperability so we can get ready for our first TIE.
First of all, do we want to use a private email list to discuss or do
we want to use the wfxml group?
Since WfXML-R spec might refer to RESTful security, this might not be
a bad place but I am opened to other suggestion (could be on the WfMC
board but not everyone is a member...)
Here is a recap to get everyone up to speed.
With OWS-5, we implemented security using OpenID + simplified version
of OAuth with pre-approved transactions. This allowed us to do one
one-time registration and one-time user grant access, then the OAuth
transaction is reduced to a one trip secure transaction.
Keith has suggested to bypass the consumer/provider registration by
using SSL.
Rather than requiring user to pre-approve transaction, Keith has
suggested to follow the OAuth protocol when the workflow is installed
but not executed. Appropriate tokens would be acquired by the
installer guy from the right servers and maintained by the workflow.
When the workflow is run, tokens would be exchanged for access
tokens. Workflow could only run by the installer or a person allowed
by the installer. Service provider would think in any case that the
user is the installer unless we can also add the end-user openid for
auditing purpose.
For OWS-6 we also need to demonstrate temporary trust. For example,
NASA might have to temporary trust the California Fire Fighter OpenID
provider, determine that Joe is a valid firefighter and has the
tasking role as granted by his organization.
Looking forward to hear from you guys.
Thanks again.
Pat.
cappelaere
Dec 12, 2008, 10:08:44 AM12/12/08
to WfXML
Thanks Pat that is a very good summary.
It seems that the pattern is that there is "installing", then
"enabling", then "invoking". Workflow servers usually allow some way
for a process to be installed, and this is no difference in the secure
environment. Enabling must happen synchronously with the user being
present. During enabling, OAuth protocol is used to gather all the
access tokens that will be needed by the process. After a process is
enabled, instances of the process can be invoked and can run
asynchronously without the user being available at the time.
This can happen in different orders in some cases, but normally will
be "installing", then "enabling", then "invoking".
These can be done by the same person, or by different people. It is
possible that a process definition is installed once, the definition
is enabled once, and then many instances run. Or it might be that it
is installed once, and then enabled every time it is invoked. It is
possible for enabling to happen after invoking, and it is possible
that enabling will be done uniquely for each instance. It is also
possible that a single process definition may be enabled by multiple
people, and those multiple enablements will need to be preserved, but
when invoked, only one enablement will be involved with with the
running process. Finally, it is possible (although I think unlikely)
that different people may enable different parts of a process, and it
is not necessary that all part of the process be enabled at the same
time. All of these patterns depend upon the requirements.
The workflow process acts on behalf of the person who enables it.
Thus is Joe enables it, then it will make requests that will see
things that is a subset of what Joe has access to. The process can
not be enabled to see things that the enabler does not have access
to. The services being called from the workflow know with certainty
who the person was who enabled the interactions.
When I speak above of "processes" being enabled, I really mean a
bigger collection. Lets call it an "application". Enablement will
typically happen for an application, and there may be many process
definitions in an application. An application, however, is a unit
that someone can be responsible for. Typically an application will be
installed at one time in its entirety, but there is no reason to
prevent partial installations.
The enabling step uses OAuth exactly as designed. The result of an
OAuth interaction is an access token. Workflows that invoke secure
services need to be able to store those tokens that are collected
during enablement, so they can be used at run time. Workflow that
expect to be invoked securely need to be able to generate such tokens,
and remember them, together with the user that authorized them, so
that this can be verified when called. None of this is surprising
since the purpose of an OAuth interaction is to exchange an access
token, and so this handling of the access token is expected.
You can think of this "enablement" as the "preapproving of
transactions" if you wish.
-Keith
It seems that the pattern is that there is "installing", then
"enabling", then "invoking". Workflow servers usually allow some way
for a process to be installed, and this is no difference in the secure
environment. Enabling must happen synchronously with the user being
present. During enabling, OAuth protocol is used to gather all the
access tokens that will be needed by the process. After a process is
enabled, instances of the process can be invoked and can run
asynchronously without the user being available at the time.
This can happen in different orders in some cases, but normally will
be "installing", then "enabling", then "invoking".
These can be done by the same person, or by different people. It is
possible that a process definition is installed once, the definition
is enabled once, and then many instances run. Or it might be that it
is installed once, and then enabled every time it is invoked. It is
possible for enabling to happen after invoking, and it is possible
that enabling will be done uniquely for each instance. It is also
possible that a single process definition may be enabled by multiple
people, and those multiple enablements will need to be preserved, but
when invoked, only one enablement will be involved with with the
running process. Finally, it is possible (although I think unlikely)
that different people may enable different parts of a process, and it
is not necessary that all part of the process be enabled at the same
time. All of these patterns depend upon the requirements.
The workflow process acts on behalf of the person who enables it.
Thus is Joe enables it, then it will make requests that will see
things that is a subset of what Joe has access to. The process can
not be enabled to see things that the enabler does not have access
to. The services being called from the workflow know with certainty
who the person was who enabled the interactions.
When I speak above of "processes" being enabled, I really mean a
bigger collection. Lets call it an "application". Enablement will
typically happen for an application, and there may be many process
definitions in an application. An application, however, is a unit
that someone can be responsible for. Typically an application will be
installed at one time in its entirety, but there is no reason to
prevent partial installations.
The enabling step uses OAuth exactly as designed. The result of an
OAuth interaction is an access token. Workflows that invoke secure
services need to be able to store those tokens that are collected
during enablement, so they can be used at run time. Workflow that
expect to be invoked securely need to be able to generate such tokens,
and remember them, together with the user that authorized them, so
that this can be verified when called. None of this is surprising
since the purpose of an OAuth interaction is to exchange an access
token, and so this handling of the access token is expected.
You can think of this "enablement" as the "preapproving of
transactions" if you wish.
-Keith
cappelaere
Dec 12, 2008, 10:12:25 AM12/12/08
to WfXML
Keith,
Treating your WfCS as a black box, how would you publish your
workflows that have been enabled for a specific user so that the CA
fire department can discover them and Joe can execute that particular
process? You had no a-priori knowledge of Joe nor the CA fire
Department at the time you originally installed the workflow?
If I am an existing NASA valid user with the proper rights and
discover that workflow from the catalog. I want to execute it. What
are the steps to make this happen?
Do I need to talk to your sys admin, then the guy that installed that
workflow to get added to the list?
Do I need to be trained on how to install that workflow on that
server?
Pat.
Treating your WfCS as a black box, how would you publish your
workflows that have been enabled for a specific user so that the CA
fire department can discover them and Joe can execute that particular
process? You had no a-priori knowledge of Joe nor the CA fire
Department at the time you originally installed the workflow?
If I am an existing NASA valid user with the proper rights and
discover that workflow from the catalog. I want to execute it. What
are the steps to make this happen?
Do I need to talk to your sys admin, then the guy that installed that
workflow to get added to the list?
Do I need to be trained on how to install that workflow on that
server?
Pat.
cappelaere
Dec 12, 2008, 10:12:25 AM12/12/08
to WfXML
Keith,
Treating your WfCS as a black box, how would you publish your
workflows that have been enabled for a specific user so that the CA
fire department can discover them and Joe can execute that particular
process? You had no a-priori knowledge of Joe nor the CA fire
Department at the time you originally installed the workflow?
If I am an existing NASA valid user with the proper rights and
discover that workflow from the catalog. I want to execute it. What
are the steps to make this happen?
Do I need to talk to your sys admin, then the guy that installed that
workflow to get added to the list?
Do I need to be trained on how to install that workflow on that
server?
Pat.
On Dec 12, 10:08 am, cappelaere <cappela...@gmail.com> wrote:
Treating your WfCS as a black box, how would you publish your
workflows that have been enabled for a specific user so that the CA
fire department can discover them and Joe can execute that particular
process? You had no a-priori knowledge of Joe nor the CA fire
Department at the time you originally installed the workflow?
If I am an existing NASA valid user with the proper rights and
discover that workflow from the catalog. I want to execute it. What
are the steps to make this happen?
Do I need to talk to your sys admin, then the guy that installed that
workflow to get added to the list?
Do I need to be trained on how to install that workflow on that
server?
Pat.
On Dec 12, 10:08 am, cappelaere <cappela...@gmail.com> wrote:
cappelaere
Dec 12, 2008, 12:00:36 PM12/12/08
to WfXML
That is a good question and would like to discuss it. I see two main
patterns:
"global select" - This is the situation where a particular person
would enable a workflow and then advertise its availability for use by
others. For example, the mayor of a city makes a process that
accesses services that are available only to a mayor, and produce
things which his staff or other specific individuals. In this case
there is really only one enablement. The mayor control access to
this, so the potential callers must ask him for access to this
service. Or he must set up a rule that will allow access based on
specified conditions. This is the pattern that New York Times uses to
relay information from Associated Press, or that Amazon.com uses to
relay information from a partner.
"individual select" - This is a situation where a process is designed
to access personal information about the invoker: e.g. it accesses
your own personal medical information. In this case there is a single
advertised process, but every invoker needs to enable the process, and
it will remember that enablement in case the same user invokes the
process again. This is the pattern that Facebook and iGoogle use to
allow the installation of gadgets that access personal information.
There are other possible patterns, but my guess is that other patterns
will be relatively obscure. You scenario seems not to be one of
these. If I understand it correctly, there is a main process which is
"individual select" (that is it is not enabled by the person who
installed, but must be enabled by CA Fire Department) and they want to
make this "global select" (any CA Fireman can use). My recommendation
is that the CA Fire Department publish a trivial (one step) process
which is global select, which calls the individual select process.
>I am an existing NASA valid user....What are the steps to make this happen?
This will depend on the kind of workflow. For example, to access the
workflow that the CA Fire Department published (above) you need to
become a CA Fireman, then you can access it. Gaining access rights is
not covered in this proposal. This proposal focuses exclusively on
"proving" that a service is acting on your behalf when you already
have the right. For global select processes, the access needs to be
controlled either by rules or some other access control mechanism.
You might need to call up the administrator to be put on a list. You
might need to sign up for an account at the organization. You might
have to give them a credit card number so you can be billed for every
invocation. Global select processes are pretty much pure black box
services -- you have no idea there is workflow behind them.
In the case of "individual select" almost no access control needs to
be provided to the basic advertised service, since nothing can be done
until it is enabled. Of course, the association between the invoking
individual and the resulting enablement needs to be strictly enforced,
but that is automatic and requires no human intervention. Individual
select requires that you have access to the services being called by
the process, and so you are aware that it is a workflow. Enablement
gives the process the right to access services on your behalf, without
you having to give away your password or allow uncontrolled access.
-Keith
patterns:
"global select" - This is the situation where a particular person
would enable a workflow and then advertise its availability for use by
others. For example, the mayor of a city makes a process that
accesses services that are available only to a mayor, and produce
things which his staff or other specific individuals. In this case
there is really only one enablement. The mayor control access to
this, so the potential callers must ask him for access to this
service. Or he must set up a rule that will allow access based on
specified conditions. This is the pattern that New York Times uses to
relay information from Associated Press, or that Amazon.com uses to
relay information from a partner.
"individual select" - This is a situation where a process is designed
to access personal information about the invoker: e.g. it accesses
your own personal medical information. In this case there is a single
advertised process, but every invoker needs to enable the process, and
it will remember that enablement in case the same user invokes the
process again. This is the pattern that Facebook and iGoogle use to
allow the installation of gadgets that access personal information.
There are other possible patterns, but my guess is that other patterns
will be relatively obscure. You scenario seems not to be one of
these. If I understand it correctly, there is a main process which is
"individual select" (that is it is not enabled by the person who
installed, but must be enabled by CA Fire Department) and they want to
make this "global select" (any CA Fireman can use). My recommendation
is that the CA Fire Department publish a trivial (one step) process
which is global select, which calls the individual select process.
>I am an existing NASA valid user....What are the steps to make this happen?
This will depend on the kind of workflow. For example, to access the
workflow that the CA Fire Department published (above) you need to
become a CA Fireman, then you can access it. Gaining access rights is
not covered in this proposal. This proposal focuses exclusively on
"proving" that a service is acting on your behalf when you already
have the right. For global select processes, the access needs to be
controlled either by rules or some other access control mechanism.
You might need to call up the administrator to be put on a list. You
might need to sign up for an account at the organization. You might
have to give them a credit card number so you can be billed for every
invocation. Global select processes are pretty much pure black box
services -- you have no idea there is workflow behind them.
In the case of "individual select" almost no access control needs to
be provided to the basic advertised service, since nothing can be done
until it is enabled. Of course, the association between the invoking
individual and the resulting enablement needs to be strictly enforced,
but that is automatic and requires no human intervention. Individual
select requires that you have access to the services being called by
the process, and so you are aware that it is a workflow. Enablement
gives the process the right to access services on your behalf, without
you having to give away your password or allow uncontrolled access.
-Keith
cappelaere
Dec 12, 2008, 1:21:44 PM12/12/08
to WfXML
Keith,
So you are advocating a two-step process to run a workflow.
User needs to enable it then execute it.
How does the engine know what to do?
Does it check with every participant's activity for possible OAUTH
access?
Then user is requested to enter authorization token
Then token is passed to right participant
Then exchange for an access token
and then stored somewhere?
If activity is a subflow or an external workflow, do we need to pass
the request out to that subflow/workflow? If yes, how?
Pat.
So you are advocating a two-step process to run a workflow.
User needs to enable it then execute it.
How does the engine know what to do?
Does it check with every participant's activity for possible OAUTH
access?
Then user is requested to enter authorization token
Then token is passed to right participant
Then exchange for an access token
and then stored somewhere?
If activity is a subflow or an external workflow, do we need to pass
the request out to that subflow/workflow? If yes, how?
Pat.
Reply all
Reply to author
Forward
0 new messages