Could we leverage OpenID + OAuth and if yes, how?
cappelaere
assumption that OpenID was required).
I would like to explore what if OAuth could actually leveraged the
presence of OpenID and OpenID servers.
Here is a mixed scenario:
OAuth request comes in to a service provider (SP) over SSL from an
unknown application consumer (AC).
AC claims that User A (UA) has authorized it to access resource realm
R on SP.
SP turns around and checks with OpenID provider (OP) for user
confirmation. This is similar to what users are already used to do
but in this case the wording might be a little more expansive such as:
Do you trust AC to access resources "R" on server "SP" on your behalf?
User can say yes/no and even grant pernament access... Since user is
not necessarily present, it would have to be done via a user selected
notification mechanism: email, phone, sms... which is what OP already
does.
This also allows SP to verify user identity and also get access to
user profile if granted by user. If profile contains an extended
attribute such as "role" and is granted by a trusted organization, SP
could even grant UA additional access rights such as tasking a
satellite in our case.
SP does not need to know UA ahead of time. SP just needs to accept
(trust?) that OP which is what SP has to do to authenticate users
itself anyway.
It turns out that OpenID is very extensible. It has been extended for
SREG and PAPE so it could easily be extended for OAUTH. We just need
a new namespace like: http://specs.openid.net/extensions/oauth/1.0
For the purpose of the OWS-6 demo, we could demonstrate both ways and
document our recommendation for best practices. This may end up
simplifying our effort by an order of magnitude but I am not sure what
people think about this.
Comment? Feedback?
Thanks,
Pat.
Keith
was a complication, but I worked through some scenarios in detail, and
I found that (1) remaining separate did not increase the complexity of
interaction, and (2) it gave some very specific benefits.
I. OAuth can cross security domains nicely
When you AC is trying to get access to SP they can agree to use OAuth
without having to compromise on any aspect of security. In order to
hook AC and SP together, the user must authenticate to AC using
whatever mechanism that AC demands, and the user must authenticate to
SP using whatever mechanism SP demands.
Saying that both AC and SP use OpenID does not mean that you will be
able to use the SAME id at both. I personally would like to have a
single ID that works everywhere, but that is the aspect of OpenID that
in question. AC may require an OpenID from one authority, and SP may
require an OpenID from another authority. OpenID allows the user to
login to AC and SP without giving a password to AC or SP, and that is
an advantage. OpenID is a protocol, not a signing authority or
identity provider. Sites often accept OpenIDs from only subset of all
OpenID providers.
II. Can we demand that all SPs accept a particular identity provider?
Can you require that a SP use OpenID to a particular identity
provider? Probably not. We must assume that there will be hundreds
of identity providers, and we must assume that a particular SP will
allow IDs from only a subset of these identity providers, and in many
cases the SP will have its own identity provider service (e.g. a bank
that requires you have a user account with that bank, and that you log
in with the username/password that you have registered with them).
Assuming that all SPs will use a particular identity provider becomes
a house of cards problem: If one AC calls 10 SPs, and each SP calls
in turn 10 more SPs, that means you have 110 SPs that all must allow a
particular identity provider. If any of them don't accept that
particular provider your process crumbles. Instead, we must assume
that each SP might require a different ID (OpenID or other).
If the US government, in cooperation with all other governments, came
together to say they would provide an identity provider system based
on, say, passport numbers, you might be able to assume that all SPs
would allow this ID, but we are a long ways from this situation.
Microsoft tried to do this a few years back, and it was a failure.
Others have tried as well. It may happen some day, but for the next
decade we can assume that there will be a loosly federated system of
id providers, and SPs will allow a subset of them.
III. Can we require OAuth?
Back to workflow: if you want to have a workflow that will connect to
any SP, it is reasonable to require that service to implement OAuth,
because OAuth does not put demands or assumptions on authorization or
access control. The only demand it makes is for the SP to generate
Access Tokens which allow the real user to reserve very specifically
limited access (the exact limits depend upon the SP, and can be
limited in any fine detail that is desired). Requiring Access Tokens
seems to be a reasonable requirement because it does not expose the
service nor does it require that they trust anything that they don't
want to trust.
IV. Does this automatically give access?
This discussion has been simply about allowing a program to leverage
an access permission that already exists. The user (I mean a real
human being here) must have permission to access SP by some out of
band means. They may get this permission based on being a member of a
particular group on a particular identity provider. Thus a particular
service may be available to all Army personnel above a particular
rank. Another service may be available because you have an account at
a particular bank.
A given process that accesses a Bank and accesses a service from the
Army must be prepared that they Army and the Bank may not consume the
same OpenID. The SP for the Army will go to the official Army source
to verify that you are a particular rank, and will not trust a claim
at "myopenid.com" that you are an Army General. You are going to have
to provide whatever credentials it needs to be sure you are an Army
employee of a particular rank. You will not be able to tell the
Bank's SP to trust a particular OpenID either. The bank will not
trust "myopenid.com" that you are the owner of a particular bank
account. You are going to have to provide the credentials to prove
that you are a member of the Bank. We might wish it were different,
but that is reality for now.
OAuth handles this nicely. The process accessing both of these is
"enabled" (gets the tokens) at enablement time you will log in to the
Army system using Army credentials, and the Bank system using Bank
credentials. You don't have to assume anything about what they will or
will not allow for an ID.
-Keith
Keith
Pat G Cappelaere
On Dec 13, 2008, at 12:47 PM, Keith wrote:
>
> At first, I thought that OAuth's desire to remain separate from OpenID
> was a complication, but I worked through some scenarios in detail, and
> I found that (1) remaining separate did not increase the complexity of
> interaction, and (2) it gave some very specific benefits.
>
> I. OAuth can cross security domains nicely
>
> When you AC is trying to get access to SP they can agree to use OAuth
> without having to compromise on any aspect of security. In order to
> hook AC and SP together, the user must authenticate to AC using
> whatever mechanism that AC demands, and the user must authenticate to
> SP using whatever mechanism SP demands.
>
> Saying that both AC and SP use OpenID does not mean that you will be
> able to use the SAME id at both. I personally would like to have a
> single ID that works everywhere, but that is the aspect of OpenID that
> in question. AC may require an OpenID from one authority, and SP may
> require an OpenID from another authority. OpenID allows the user to
> login to AC and SP without giving a password to AC or SP, and that is
> an advantage. OpenID is a protocol, not a signing authority or
> identity provider. Sites often accept OpenIDs from only subset of all
> OpenID providers.
Not sure where this is going here. the user will use a single
OpenID. Hopefully this OpenID will be acceped everywhere otherwise it
will become very hard for the cascading workflows to pass the right id
to the right service.
This is a major asumption of the scenarios.
The SP will eventually have to accept the OpenID server of the
firefighter that is trying to make the request.
>
>
> II. Can we demand that all SPs accept a particular identity provider?
>
> Can you require that a SP use OpenID to a particular identity
> provider? Probably not. We must assume that there will be hundreds
> of identity providers, and we must assume that a particular SP will
> allow IDs from only a subset of these identity providers, and in many
> cases the SP will have its own identity provider service (e.g. a bank
> that requires you have a user account with that bank, and that you log
> in with the username/password that you have registered with them).
> Assuming that all SPs will use a particular identity provider becomes
> a house of cards problem: If one AC calls 10 SPs, and each SP calls
> in turn 10 more SPs, that means you have 110 SPs that all must allow a
> particular identity provider. If any of them don't accept that
> particular provider your process crumbles. Instead, we must assume
> that each SP might require a different ID (OpenID or other).
>
> If the US government, in cooperation with all other governments, came
> together to say they would provide an identity provider system based
> on, say, passport numbers, you might be able to assume that all SPs
> would allow this ID, but we are a long ways from this situation.
> Microsoft tried to do this a few years back, and it was a failure.
> Others have tried as well. It may happen some day, but for the next
> decade we can assume that there will be a loosly federated system of
> id providers, and SPs will allow a subset of them.
We are not requiring a sole Identity Provider. This is a federated
identity environment. We are only requiring to the SP's to accept
either any Identity Providers or at least a minimum list to can grow
over time when temporary trust is required.
>
>
> III. Can we require OAuth?
>
> Back to workflow: if you want to have a workflow that will connect to
> any SP, it is reasonable to require that service to implement OAuth,
> because OAuth does not put demands or assumptions on authorization or
> access control. The only demand it makes is for the SP to generate
> Access Tokens which allow the real user to reserve very specifically
> limited access (the exact limits depend upon the SP, and can be
> limited in any fine detail that is desired). Requiring Access Tokens
> seems to be a reasonable requirement because it does not expose the
> service nor does it require that they trust anything that they don't
> want to trust.
>
There is a trade to be made here. I believe that an SP can
legitimately request the user to use its own infrastructure for
delegation of authority, token distribution and maintenance. This
would be a thick SP.
Thin SPs might want to delegate that management to the User OP. This
is not a requirement though but it might make everybody's life easier
(user and SP developer)
> IV. Does this automatically give access?
>
> This discussion has been simply about allowing a program to leverage
> an access permission that already exists. The user (I mean a real
> human being here) must have permission to access SP by some out of
> band means. They may get this permission based on being a member of a
> particular group on a particular identity provider. Thus a particular
> service may be available to all Army personnel above a particular
> rank. Another service may be available because you have an account at
> a particular bank.
>
This is exactly right. In the first case, the SP does not know a-
priori the user or the permission that the user may have been
granted. It is discovered at runtime during an attribute exchange
(with the user permission, of course)
> A given process that accesses a Bank and accesses a service from the
> Army must be prepared that they Army and the Bank may not consume the
> same OpenID. The SP for the Army will go to the official Army source
> to verify that you are a particular rank, and will not trust a claim
> at "myopenid.com" that you are an Army General. You are going to have
> to provide whatever credentials it needs to be sure you are an Army
> employee of a particular rank. You will not be able to tell the
> Bank's SP to trust a particular OpenID either. The bank will not
> trust "myopenid.com" that you are the owner of a particular bank
> account. You are going to have to provide the credentials to prove
> that you are a member of the Bank. We might wish it were different,
> but that is reality for now.
>
This is true. the assumption is that there is a federation of trusted
organizations (or temporary trusted organizations)
This is our current sandbox.
> OAuth handles this nicely. The process accessing both of these is
> "enabled" (gets the tokens) at enablement time you will log in to the
> Army system using Army credentials, and the Bank system using Bank
> credentials. You don't have to assume anything about what they will or
> will not allow for an ID.
>
As I said, I would love to see an elaboration of that extended use-
case (which I think is out of scope but really interesting). What we
learn will be detailed in the engineering report. So we want to
continue on that route too.
My concerns are as follows:
- Grant access and token management. This is non trivial and If all
the SP's do it differently, this will confuse the user. I am not sure
I know how to enforce consistency across organizations.
- Determination at enablement time of what tokens are necessary
based on introspection of all the participants and activities,
subflows and external workflows
- Liability if access tokens leak at the application level. They can
be redeemed anywhere in this case.
- If this is something specific to workflow enactment services, not
sure we have solved the security problem.
Are we also requiring certificates for all SP's to support https?
Thanks,
Pat.