This is an attempt to provide specific detail around the OWS-6 scenario. In order to provide sufficient detail, we will focus on the "Weather Subflow" as outlined in the
OWS-6 documentation
. (Sorry the OWS site is password protected, but links are provided for those who have passwords.)
The basic setting is that there is an airport next to an industrial district with a fire. The subworkflow is given information about the fire, gathers information from the weather service, and then invokes a plume modeling service to calculate the extent of the plume of smoke, so that emergency personnel can make decisions about whether to evacuate the airport or not, and whether to close the runway or not.
Andy Gets An Idea
Andy is the name of the character who is going to put together the workflow to accomplish this. It is not clear if this work is done at the time of the accident, or weeks earlier, so the precise timeline is fuzzy, but in either case all the same things must be done.
Andy is asked if it is possible to make a service that would accept as input specific information about a fire in a specific world location, and would return a plum model about that particular smoke plume that would result.
Andy discovers that there is a service provided by a University to do the plume calculation. It requires as input a weather forecast model for the region. After a bit more research he finds that there is a commercial service who can provide the weather model that is required. He then decides that it will be possible to use a workflow to pick up and distribute the information between the services and provide the result.
Locating the Workflow Service
Andy locates a workflow server to use for this workflow, which is hosted by his company, and which he is able to use for free. The workflow server is administered by Dave. He talks to Dave, and Dave sets up an account on the workflow service which allows Andy access to it and to run workflows on it, as long as the amount stays under a reasonable level (e.g. less than 100 workflow invocations per day). Andy finds this limitation acceptable.
The workflow service tracks people by OpenID, and so Andy gives Dave his OpenID, and Dave sets the access rights so that Andy is able to access the workflow server using his OpenID.
Creating the Workflow Process Definition
Andy then uses a process modelling tool to draw a diagram of the service, which looks like this:
In order to make a step in the process that calls the weather service, he needs to know the details of the data that must be sent and received, and the specific formats of each. Unclear at this time how he learns this.
In order to make the step int he process that call the University plume service, he needs to know the details of the data that must be sent and received, and the specific formats of each. Unclear at this time how he learns this.
Using workflow specific mechanism (script language, extensions, whatever) he can create a step between these two call that will manipulate the data as required to be passed from one service to the other.
He can now log into the workflow server, install the process definition, and because this is the future it has no bugs in it and is ready to run immediately except for gaining access to the services involved.
Access to the Weather Calculation
The weather model is a for-profit service which will charge a fee for every invocation of the service. Andy must sign up for an account with the service which has a username and a password, and where he must also specify a credit card number to be charged. The organization sponsoring Andy's work provides a credit card number which Andy enter into the account.
The lawyers have convinced the management of the weather company that they can not trust an external OpenID provider to authenticate the user, and so they require a password on the account that Andy must remember. This way they guard that password internally and be 100% assured that if that password gets leaked and abused, they can be 100% sure that it was leaked by Andy, and that he is liable for any costs that are incurred.
Access to the University
The University does not charge for the service, but it also does not allow their service to be invoked by just anyone. Andy calls someone at the University, and tells him about the project, and convinces him that it is a worthwhile deal. The University will accept an OpenID authentication, and so Andy gives the University his OpenID, and the university makes an internal setting that allows Andy (his OpenID) access to the service.
Enabling the workflow
Now that the workflow definition is installed into the workflow server, and now that he has access to the services in question, he must enable the workflow.
He accesses the "Enable" UI on the workflow. This causes the workflow engine to determine how many service calls the workflow process will (possibly) make, and it finds that there will be two.
Using OAuth discovery, the workflow engine request to each service for the OAuth Discovery document which tells it which service addresses and how to proceed with OAuth exchange.
The workflow engine then requests a Request Token from each service. The workflow engine UI at that point displays to Andy that for each service it has a Request Token, which needs to be validated so that it can get the Access Token.
Andy then goes to the Weather Service, and logs in using the password provided by that company.
There he sees that a a request has been made by the workflow engine to access the weather service. He approves that request, and at the same time puts whatever limitations possible on that request. The limitations depend upon the possibilities defined by the Weather Service for limiting access. For example, they might have a maximum dollar value / day that can be accessed through that token. Or they might have a restriction about the geographical region, or quality of results. Andy can decide at this time what limitations to place to prevent the workflow from accidentally being used and costing Andy's organization a large amount of unnecessary charges. The weather service request token is now validated.
Andy then logs into the University plume portal using his normal OpenID mechanism. (Note: he will probably not actually see this screen since he already has a valid session with the OpenID identity provider, this authentication will take place without bothering the user.)
He sees evidence that a similar request for access has been made by his workflow process.
Again, while logged in and authenticated, he approves the access under his account. The University service request token is now validated.
Andy returns to the workflow engine "Enable" UI.
For each of the two services, he clicks a button to indicate that the request token has been validated, and that it should go ahead and pick up the Access token. The workflow engine uses the request token to get an Access token for each of the two services. It stores those access token with the process definition as if they were passwords, guarded in the same way that it would guard passwords. Note that Andy never gave any password to the workflow engine.
Advertisement of the Workflow Service
After testing that the workflow service works, Andy wants to allow others to use this service. He lists it as a service, but he does not just let anyone call it. The workflow requires very specific data format as input, and so he needs to specify the format of the input. (I am not clear on how this is specified)
Accessing the workflow
Bob is interested in using Andy's workflow service. Bob contacts Andy and asks for permission. (How Andy decides to let Bob access is out of scope for this discussion, but remember that the Weather Service costs money, and so there is an open question as to how this is reconciled. Perhaps Andy and Bob work for the same company, or perhaps there is an agreement to charge Bob back at the end of the month for costs incurred.) Andy is willing to trust Bob's OpenID, and so sets up permission to Bob's OpenID.
Bob then can write a program that will invoke Andy's workflow service.
Bob then can enable that program: the program will request a Request token from Andy's service. Bob will then access the UI of the workflow engine, log in with his OpenID, see that there is a request for a token, and validate the request. He goes back to his program, indicates that the Request token is valid, so the program can use it to pick up the Access token which it will store as if it was a password to access the workflow service.
Now Bob can run his program, that accesses Andy's workflow (using the Access token enabled by Bob), that access the Weather Service (using the Access Token enabled by Andy), and the University plume calculation (using the Access token enabled by Andy), and the final results are delivered to Bob.
Discussion
All connections are SSL & HTTPS to ensure privacy.
Dave did not have to be involved in connecting the workflow engine to the University or to the Weather service. Andy was able to establish these secure connections without involving Dave who otherwise manages the workflow server.
Dave's only role was to allow Andy access to the server.
There was no pre-existing connection between Dave's server and the University or the Weather Service. Andy was free to use literally any service on the internet without limitation.
Andy had to "go to the Weather Service to validate the request". In most OAuth scenarios this is accomplished by a browser redirect to that site. That of course is controversial because he might fall prey to a phishing attempt. This can only happen if Dave has set up a server to do this, so Andy's willingness to allow a browser redirect depends on how much he trusts Dave. Otherwise, the scenario above is the same regardless of whether the browser is automatically redirected to the service site, or whether Andy has to use a "Favorites" URL to access the site.
Dave did not have to be involved in allowing Bob to access the workflow service because the workflow service has an ability to grant permission to run each individual workflow to an OpenID user.
Andy never gives his Weather Service password to the workflow engine. He only uses it to log into the Weather Service. When he validates the request from the workflow service to the Weather Service, his is proving that he has access to the workflow service, and that he intended the connection. All requests to the Weather Service using this token will be charged to Andy's account there.
Andy has 100% reliable evidence that the request was made on behalf of Bob, and he can make a record of this fact, so that later he will be able to charge Bob for the costs incurred for all requests made by Bob.
What if the information is secret? If the University is including secret information in the result, it must consider this when it gives access to Andy. For Andy to receive the secret information, he must agree to the proper handling of that information.
If the results of the workflow still contains secret information, then this must be considered when Andy gives Bob access. Andy must make sure that Bob is allowed to have access, and that Bob will handle the information properly.
It is possible that the University returns secret information, but Andy's workflow cleans that out of the data. In this case, there is no secret information in the returned data, so there are no special requirements on Bob in this regard.
There is no attempt to avoid denial of service attacks. Any web service is vulnerable to this, since any program on the internet can open a socket connection to any other computer. Distributed denial of service attacks can be promoted against any web server, and the same is true of web services. Our goal then should simply be to make sure that we can reject fraudulent requests quickly and without a lot of complicated processing.
There is no need for Dave to set up a consumer id between the workflow server and either of the service providers. The consumer id is picked up automatically by Discovery. This means that anyone on the internet could exercise the discovery mechanism (which is simply a request of a data page with the required information on it). Given that information, anyone on the internet could request a request token. This is roughly equivalent to hackers going to any e-commerce site, putting something in a shopping cart anonymously, and then abandoning the shopping cart. Most e-commerce sites have nothing to prevent you from doing this. The danger is that someone will run up a million shopping carts, but this danger seems to be either very low risk, or there are techniques to address it. Similarly, someone might request a million request tokens. The same techniques would need to be used to avoid this.
If a service provider wishes, it can turn off discovery. This will not prevent any distributed denial of service attacks, but allow the requests to be terminated before a request token is generated. Turning off discovery means that Andy will have to configure the process definition with consumer ids for those services that are needed. Dave could do this as well, if Dave knew the services that Andy wants to call in the process. Thus there is a manual workaround for a company that does not want to support OAuth Discovery, but given that creating and storing a request token for a day is such a lightweight thing, it is doubtful that anyone would want to incur such a high cost for such a low risk.
The request token in real life will have a timeout duration. Andy will have to go and validate the request within a certain period of time. That period of time will depend on the whims of the service provider. Request tokens a very small pieces of data a few hundred bytes and probably never more than 1K bytes, so the cost of maintaining a lot of them is small. There is a possibility that someone may run up millions of request tokens and never validate them, so there must be a mechanism to remove unvalidated request token. A time period of one hour to one day would seem to be sufficient. If the request is not validated in that time, it would be deleted and discarded. The workflow enabling screen would reset to requesting access.
Last edited by kswenson myopenid com 12/15/2008(Effective date 12/15/2008)
Detailed Plume Scenario
This is an attempt to provide specific detail around the OWS-6 scenario. In order to provide sufficient detail, we will focus on the "Weather Subflow" as outlined in the OWS-6 documentation . (Sorry the OWS site is password protected, but links are provided for those who have passwords.)
The basic setting is that there is an airport next to an industrial district with a fire. The subworkflow is given information about the fire, gathers information from the weather service, and then invokes a plume modeling service to calculate the extent of the plume of smoke, so that emergency personnel can make decisions about whether to evacuate the airport or not, and whether to close the runway or not.
Andy Gets An Idea
Andy is the name of the character who is going to put together the workflow to accomplish this. It is not clear if this work is done at the time of the accident, or weeks earlier, so the precise timeline is fuzzy, but in either case all the same things must be done.
Andy is asked if it is possible to make a service that would accept as input specific information about a fire in a specific world location, and would return a plum model about that particular smoke plume that would result.
Andy discovers that there is a service provided by a University to do the plume calculation. It requires as input a weather forecast model for the region. After a bit more research he finds that there is a commercial service who can provide the weather model that is required. He then decides that it will be possible to use a workflow to pick up and distribute the information between the services and provide the result.
Locating the Workflow Service
Andy locates a workflow server to use for this workflow, which is hosted by his company, and which he is able to use for free. The workflow server is administered by Dave. He talks to Dave, and Dave sets up an account on the workflow service which allows Andy access to it and to run workflows on it, as long as the amount stays under a reasonable level (e.g. less than 100 workflow invocations per day). Andy finds this limitation acceptable.
The workflow service tracks people by OpenID, and so Andy gives Dave his OpenID, and Dave sets the access rights so that Andy is able to access the workflow server using his OpenID.
Creating the Workflow Process Definition
Andy then uses a process modelling tool to draw a diagram of the service, which looks like this:
In order to make a step in the process that calls the weather service, he needs to know the details of the data that must be sent and received, and the specific formats of each. Unclear at this time how he learns this.
In order to make the step int he process that call the University plume service, he needs to know the details of the data that must be sent and received, and the specific formats of each. Unclear at this time how he learns this.
Using workflow specific mechanism (script language, extensions, whatever) he can create a step between these two call that will manipulate the data as required to be passed from one service to the other.
He can now log into the workflow server, install the process definition, and because this is the future it has no bugs in it and is ready to run immediately except for gaining access to the services involved.
Access to the Weather Calculation
The weather model is a for-profit service which will charge a fee for every invocation of the service. Andy must sign up for an account with the service which has a username and a password, and where he must also specify a credit card number to be charged. The organization sponsoring Andy's work provides a credit card number which Andy enter into the account.
The lawyers have convinced the management of the weather company that they can not trust an external OpenID provider to authenticate the user, and so they require a password on the account that Andy must remember. This way they guard that password internally and be 100% assured that if that password gets leaked and abused, they can be 100% sure that it was leaked by Andy, and that he is liable for any costs that are incurred.
Access to the University
The University does not charge for the service, but it also does not allow their service to be invoked by just anyone. Andy calls someone at the University, and tells him about the project, and convinces him that it is a worthwhile deal. The University will accept an OpenID authentication, and so Andy gives the University his OpenID, and the university makes an internal setting that allows Andy (his OpenID) access to the service.
Enabling the workflow
Now that the workflow definition is installed into the workflow server, and now that he has access to the services in question, he must enable the workflow.
He accesses the "Enable" UI on the workflow. This causes the workflow engine to determine how many service calls the workflow process will (possibly) make, and it finds that there will be two.
Using OAuth discovery, the workflow engine request to each service for the OAuth Discovery document which tells it which service addresses and how to proceed with OAuth exchange.
The workflow engine then requests a Request Token from each service. The workflow engine UI at that point displays to Andy that for each service it has a Request Token, which needs to be validated so that it can get the Access Token.
Andy then goes to the Weather Service, and logs in using the password provided by that company.
There he sees that a a request has been made by the workflow engine to access the weather service. He approves that request, and at the same time puts whatever limitations possible on that request. The limitations depend upon the possibilities defined by the Weather Service for limiting access. For example, they might have a maximum dollar value / day that can be accessed through that token. Or they might have a restriction about the geographical region, or quality of results. Andy can decide at this time what limitations to place to prevent the workflow from accidentally being used and costing Andy's organization a large amount of unnecessary charges. The weather service request token is now validated.
Andy then logs into the University plume portal using his normal OpenID mechanism. (Note: he will probably not actually see this screen since he already has a valid session with the OpenID identity provider, this authentication will take place without bothering the user.)
He sees evidence that a similar request for access has been made by his workflow process.
Again, while logged in and authenticated, he approves the access under his account. The University service request token is now validated.
Andy returns to the workflow engine "Enable" UI.
For each of the two services, he clicks a button to indicate that the request token has been validated, and that it should go ahead and pick up the Access token. The workflow engine uses the request token to get an Access token for each of the two services. It stores those access token with the process definition as if they were passwords, guarded in the same way that it would guard passwords. Note that Andy never gave any password to the workflow engine.
Advertisement of the Workflow Service
After testing that the workflow service works, Andy wants to allow others to use this service. He lists it as a service, but he does not just let anyone call it. The workflow requires very specific data format as input, and so he needs to specify the format of the input. (I am not clear on how this is specified)
Accessing the workflow
Bob is interested in using Andy's workflow service. Bob contacts Andy and asks for permission. (How Andy decides to let Bob access is out of scope for this discussion, but remember that the Weather Service costs money, and so there is an open question as to how this is reconciled. Perhaps Andy and Bob work for the same company, or perhaps there is an agreement to charge Bob back at the end of the month for costs incurred.) Andy is willing to trust Bob's OpenID, and so sets up permission to Bob's OpenID.
Bob then can write a program that will invoke Andy's workflow service.
Bob then can enable that program: the program will request a Request token from Andy's service. Bob will then access the UI of the workflow engine, log in with his OpenID, see that there is a request for a token, and validate the request. He goes back to his program, indicates that the Request token is valid, so the program can use it to pick up the Access token which it will store as if it was a password to access the workflow service.
Now Bob can run his program, that accesses Andy's workflow (using the Access token enabled by Bob), that access the Weather Service (using the Access Token enabled by Andy), and the University plume calculation (using the Access token enabled by Andy), and the final results are delivered to Bob.
Discussion