Consumer Registration Scalability Issues
Pat G Cappelaere
registered at the Service Provider (SP) before starting any
transactions. This is a problem for scalability.
I can think of two good reasons for doing registration though:
- This guarantees some kind of trust regarding the AC identity. SP
can ask the user that AC is requesting authorization to access user
resources (and SP knows AC)
- Sign the message to avoid tampering and playback using key/secret
Keith is proposing for SP to use https and not require a consumer
key. I think that some users might be reluctant to delegate their
authority to an unknown AC. This also requires SP to implement https
and manage certificates. This may be an issue for some SPs.
if the AC needs to connect to many SPs across many domains, this may
be a pain to do ahead of time especially if we want to discover new
capabilities in real-time and build dynamic workflows to access these
newly discovered services.
If we look at what Google does at: http://code.google.com/apis/accounts/docs/RegistrationForWebAppsAuto.html
, we could do something similar with our "organizational" OP's (the
ones that can vouch for their users).
A developer could register an Application Consumer url to the OP with
a X.509 certificate in PEM format (consumer public key). OP could
optionally verify that url is legitimate by checking the url for a
meta-tag. OP, then, provides the consumer with an openid that can be
used a the consumer key.
Now: If an AC tries to access an SP for the first time, the AC would
use its openid as consumer key and private certificate key as secret.
SP can check if the domain is trusted from current white list. SP can
then access the OP and get the AC attributes (url and pem) using AX.
SP can then verify the signature authenticity and authenticate the
AC. Next step is to ask the user for AC's authorization to access
resources... same dance.
SP & AC could use the traditional OAuth dance with request tokens,
authorization tokens and access tokens... Problem would be for the SP
to determine if the access token is still valid and has not been
revoked by the user. SP would have to check with the OP.
If this is the case, SP can simply check with OP every time to see if
grant is still active. Only problem is that it requires the OP to be
available. Advantage is that the transactions hops are now very
limited as well as SP infrastructure needs.
Let me know what you think.
Pat.
Keith
On Dec 28, 10:08 am, Pat G Cappelaere <cappela...@gmail.com> wrote:
> Keith is proposing for SP to use https and not require a consumer
> key. I think that some users might be reluctant to delegate their
> authority to an unknown AC. This also requires SP to implement https
> and manage certificates. This may be an issue for some SPs.
giving access to unknown identities or authorities. I have suggested
that identity can and must be established through the regular three-
legged OAuth protocol. If you do this, there is no question at all
about who is authorizing the transaction. The result of this is a
"access token" which is the key that guarantees authentication, access
control, and non-repudiation.
Pat has maintained that the three-legged OAuth dance is not necessary,
and that the "consumer id" is a sufficient replacement.
Eran Hammer-Lahav commented, in the presentation given at the WfMC
meeting, that there are many situations that the "consumer id" will
not be secure. He concurred that consumer id was not needed in most
situations if you are completing the three legged dance.
The reason I prefer using the "access token" is because it allow users
to set up access tokens by themselves SOMETIMES. In both approaches,
the person setting up the service must be known to the SP, and that
can never be automated.
In the access token approach, the user setting up the workflow has to
has a user account that has access to the SP. Once that account is in
place, it is possible to provision a new workflow server, and get an
access token in an automated and secure way, without bothering the
admins at the SP. One user could set up dozens of workflow processes,
on different servers, without having to bother the SP admins.
Pat's "consumer id" approach requires that for every workflow server
you set up, you must contact the SP admin by telephone or email, and
get a consumer id, and that consumer id must be managed manually.
This, I believe, is not convenient when there are a large number of
workflow servers to be used, or when you are working in a cloud
environment where the servers really don't matter, and you have to
have a consumer id for every application. This is a real scalability
problem which is not apparent in a scenario that connects a single
workflow to a single SP.
What about automating acquisition of consumer id? There is OAuth
Discovery which will automatically provide a consumer id (this is what
I prefer) but Pat can not use this because he is using the "consumer
id" as the basic token for access control. In his approach, consumer
id must be created manually. Since I favor the "access token" as the
basic token, my approach can use OAuth Discovery.
In summary: I favor the "access token" approach because it is
consistent with "Person Oriented Architecture" which treats physical
servers as unimportant, like the cloud computing. In POA, a workflow
can easily be moved to any consumer host machine without loss of
security, because the identity of the server is unimportant. The
"consumer id" is an id of the host computer itself, where the server
(consumer) that is hosting the workflow is treated as being relevant
as a server. This might be OK today, but I don't see that as the
trend for the future.
One more thing: Pat has never explained why he thinks that managing
keys for SSL is going to be more trouble than managing consumer ids.
A given server will have one SSL key to manage, and will have many
consumer ids: one consumer id for every server that wants to talk to
it. Seems to me that managing the consumer ids (which must be done
manually) will be 100 to 1000 times as much trouble as managing a
single SSL key. I simply don't understand the argument that people
will find managing SSL keys to be "an issue". What am I missing here?
Pat G Cappelaere
Thank you for responding and continuing the discussion.
Comments inline.
On Dec 29, 2008, at 4:24 PM, Keith wrote:
>
> Pat tried to characterize my position as this:
>
> On Dec 28, 10:08 am, Pat G Cappelaere <cappela...@gmail.com> wrote:
>> Keith is proposing for SP to use https and not require a consumer
>> key. I think that some users might be reluctant to delegate their
>> authority to an unknown AC. This also requires SP to implement https
>> and manage certificates. This may be an issue for some SPs.
>
> This may give a misconception of my position. I have never promoted
> giving access to unknown identities or authorities. I have suggested
> that identity can and must be established through the regular three-
> legged OAuth protocol. If you do this, there is no question at all
> about who is authorizing the transaction. The result of this is a
> "access token" which is the key that guarantees authentication, access
> control, and non-repudiation.
>
Problem 1: There is an issue since service provider needs to go back
to the user and ask for permission to allow consumer to access
resources on user's behalf. If provider cannot identify the consumer,
it cannot relay that information to the user.
Problem 2: This is a point-to-point solution that does not scale. I
can't imagine having to do this with 20+ different providers.
> Pat has maintained that the three-legged OAuth dance is not necessary,
> and that the "consumer id" is a sufficient replacement.
>
> Eran Hammer-Lahav commented, in the presentation given at the WfMC
> meeting, that there are many situations that the "consumer id" will
> not be secure. He concurred that consumer id was not needed in most
> situations if you are completing the three legged dance.
>
But there are situations when the consumer id is secure. And in those
circumstance, we need to leverage it.
It the consumer id is an openid, then there is a fairly solid
confidence of the consumer identity (as solid as the user's identity
anyway)
> The reason I prefer using the "access token" is because it allow users
> to set up access tokens by themselves SOMETIMES. In both approaches,
> the person setting up the service must be known to the SP, and that
> can never be automated.
>
> In the access token approach, the user setting up the workflow has to
> has a user account that has access to the SP. Once that account is in
> place, it is possible to provision a new workflow server, and get an
> access token in an automated and secure way, without bothering the
> admins at the SP. One user could set up dozens of workflow processes,
> on different servers, without having to bother the SP admins.
>
Problem is scaling again. Imagine having to do this across many many
SP's. How are you going to have accounts on those SP's? How are you
going to handle access revocation?
> Pat's "consumer id" approach requires that for every workflow server
> you set up, you must contact the SP admin by telephone or email, and
> get a consumer id, and that consumer id must be managed manually.
NOPE. A consumer id only needs to be registered at the local OP. The
rest is dynamic as trust relationships are built out of bounds by
security people.
>
> This, I believe, is not convenient when there are a large number of
> workflow servers to be used, or when you are working in a cloud
> environment where the servers really don't matter, and you have to
> have a consumer id for every application. This is a real scalability
> problem which is not apparent in a scenario that connects a single
> workflow to a single SP.
>
This is exactly my point. Imagine many consumers trying to talk to
many providers that are being discovered in real-time.
> What about automating acquisition of consumer id? There is OAuth
> Discovery which will automatically provide a consumer id (this is what
> I prefer) but Pat can not use this because he is using the "consumer
> id" as the basic token for access control.
Actually the consumer id is used for securing the transaction to the
provider using digital signature.
> In his approach, consumer
> id must be created manually. Since I favor the "access token" as the
> basic token, my approach can use OAuth Discovery.
>
Can you explain how OAuth Discovery automatically provide a consumer id?
> In summary: I favor the "access token" approach because it is
> consistent with "Person Oriented Architecture" which treats physical
> servers as unimportant, like the cloud computing. In POA, a workflow
> can easily be moved to any consumer host machine without loss of
> security, because the identity of the server is unimportant. The
> "consumer id" is an id of the host computer itself, where the server
> (consumer) that is hosting the workflow is treated as being relevant
> as a server. This might be OK today, but I don't see that as the
> trend for the future.
>
Transactions are based on trust. This is why Google requires
applications to register with their site to access data.
If you want access to the data, the provider needs to make sure you
will play by the rule and have an option to revoke access.
I would certainly not trust my access tokens (equivalent to my
password) being managed by software residing on another server.
Again, how would I revoke it when I have problems?
> One more thing: Pat has never explained why he thinks that managing
> keys for SSL is going to be more trouble than managing consumer ids.
> A given server will have one SSL key to manage, and will have many
> consumer ids: one consumer id for every server that wants to talk to
> it. Seems to me that managing the consumer ids (which must be done
> manually) will be 100 to 1000 times as much trouble as managing a
> single SSL key. I simply don't understand the argument that people
> will find managing SSL keys to be "an issue". What am I missing here?
Nobody has to mange Consumer ids but the OP (they are openids after
all).
I have worked with many developers that could not get their site to
use the proper SSL keys.
I agree that it would be better but cannot make it a requirement and
this is not the issue anyway so I don't really care as much.
Pat.