KantaraInitiative / wg-uma

This is the repository of all specifications related to the User Managed Access Group
http://kantarainitiative.org/confluence/display/uma/
Other
27 stars 21 forks source link

Authentication-related error details #264

Closed xmlgrrl closed 7 years ago

xmlgrrl commented 7 years ago

Mike and I were discussing how interactive claims-gathering flows would now putatively replace the previous AAT-based step-up authentication flow, and trying to figure out if we had feature parity. He said:

So the idea is to use "error_details" to send the required acr's? I think that works... it would be nice to include id_token claims, like 'acr' or others in the example. I could also see a error_details about "auth_time". Also, why do you use "issuer" in the need_info token, while it's defined as "iss" in http://openid.net/specs/openid-connect-core-1_0.html#IDToken

My response: This would be a good discussion item around enhancing error_details and aligning more closely with ID token specifics. We do have "redirect_user", which would be good for doing things like "forcing authentication", but demanding a particular authentication time freshness would mean that the client would need a concept of authentication itself, which isn't guaranteed. Perhaps these could be a good case for an OIDC extension that we could develop ourselves?

jricher commented 7 years ago

As we started to discuss on the call yesterday -- the client doesn't authenticate the RqP, the AS does. So the AS requiring the RqP to have a certain level of authentication freshness or to have presented a second factor or anything of that sort is really just the AS saying "I need to talk to the RqP". In other words, it's the same mechanism as used in normal remote claim gathering. The client doesn't need to know any details of this, just that the RqP needs to be sent to the AS to interact. Once the RqP is at the AS, the AS can look at the ticket reference to figure out which policies it's trying to fulfill and say to itself, "oh, I can ask this user to log in using their U2F fob". Since the processing is entirely inside the AS, the client doesn't need to know or do anything.

Previously, with the AAT, the client needed to know whether to send the RqP to the AS for login or for claims gathering because they were treated differently. Now the world is much simpler for the client because it just needs to send the RqP to the AS to go do-a-thing.

nynymike commented 7 years ago

The UMA AS that has the permission ticket and respective policies might not be the same server that is performing the authentication.

Even if the AS and the OP are the same, the OP authn mechanism does not necessarily have any knowledge of UMA permission tickets. In order to re-authenticate, the client would need to send the user to the authorize endpoint with something like ?prompt=login&acr_values=u2f in order to effect a re-authentication. The permission ticket may be sent as part of an OpenID Connect authentication request, but this is not standard.

Similarly, if a SAML IDP provides the federated authentication APIs, you'd need to send an authn request with the AuthnContextClassRef element. A SAML IDP would have no idea about permission tickets.

In both of the above cases, it would be helpful if the client had some information about why the policy failed at the AS.

Perhaps if you provided a sequence diagram to further illustrate how you think this might occur without telling the client anything, I could understand your proposed solution a little better.

jricher commented 7 years ago

There might be a downstream IdP that the RqP uses to authenticate to the AS, yes, but the user is still authenticating to the AS in that case. In this scenario, the AS is the OIDC/SAML client and it can send its own prompt/acr parameters. The UMA client is not the OIDC/SAML client and it never needs to know that information. The diagram here is simply UMA but I'll provide it here:

with a local user

with a remote IdP, using OIDC's auth code as example

In both of these cases, it's the AS that decides it needs a particular ACR or prompt or what have you, and it's in the position to demand it either from its local login setup or through a federation protocol with the IdP. In both of these cases, the UMA client doesn't know or care that any of this is happening and doesn't need to be told anything.

If you're talking about a different setup, where the AS is not the federated identity client and is also not where the RqP authenticates in some kind of primary authentication step, then you're going to have to explain to us how the AS gets and verifies the information about the RqP having authenticated in order to fulfill its policies. In other words, I need you to provide a diagram of how you think the system connects in what you've described above where the client would need to know anything, because what you're describing isn't in line with any of the protocols that we're discussion here (past, present, or proposed future) and doesn't make any sense.

nynymike commented 7 years ago

Ok, I'm starting to understand your idea better now...

The AS as client/SP is acceptable to me.

My idea was that the client sends the signed id_token or SAML assertion as part of the request. But I like your solution because it handles the audience value better.

jricher commented 7 years ago

The client can't send the id_token or SAML assertion to the AS because the AS is not the audience of the assertion and therefore has no way to properly validate that it's a real token pointed to the client and not something stolen from a different client. In the special case that the AS is the IdP for the client, this isn't needed either because the RqP can just log in at the AS/IdP directly.

xmlgrrl commented 7 years ago

In a "narrow" ecosystem, the AS would be the IdP. In a "medium" ecosystem, the AS can be a secondary audience for an ID token sent by the client as a claim through pre-established trust. (There are other patterns we've brought up in the past for the AS to be a claims client, such as "AS requests claims and client does act_as Bob to send them", but at present that would be some sort of extension flow.) In a "wide" ecosystem where there is no pre-established trust, you wouldn't be able to trust a pushed claim in any of the traditional ID token/assertion systems I'm familiar with because of the audience challenge.

So...it's by no means impossible for the client to push the results of identification/authentication. But in 1.0, we had a "stateless" claims collection system, and a parallel if somewhat poorly documented trust elevation system, the "stateful" AAT/authorization endpoint/authentication_context hint system.

In 2.0 we have only the former. Between the AS and the client there is no special knowledge about any identification/authentication semantics, and the AS can only give hints about what kinds of claims it needs and nothing else.

So looking at the situation, a couple of options suggest themselves:

  1. No change to 2.0 as specified now: Either deployers express the authentication-related hints they want in claim-hint language or write an extension (in which case we might want to provide some examples along these lines).
  2. Add back authentication-related hints and somehow map them to the "stateless" world, possibly having to do this per claim token profile and not just generically. (In which case this issue relates to #263.)
agropper commented 7 years ago

In our HIE of One implementation the AS offers the RqP four options for authentication: (1) Direct: username and password at the AS (2) Institutional: the RS offers to act as an IDP as an option at resource registration time (3) Federated: the AS operator whitelists an IDP (4) Self-sovereign

On Fri, Jan 6, 2017 at 9:04 PM, Eve Maler notifications@github.com wrote:

In a "narrow" ecosystem, the AS would be the IdP. In a "medium" ecosystem, the AS can be a secondary audience for an ID token sent by the client as a claim through pre-established trust. (There are other patterns we've brought up in the past for the AS to be a claims client, such as "AS requests claims and client does act_as Bob to send them" http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-04-07?src=search, but at present that would be some sort of extension flow.) In a "wide" ecosystem where there is no pre-established trust, you wouldn't be able to trust a pushed claim in any of the traditional ID token/assertion systems I'm familiar with because of the audience challenge.

So...it's by no means impossible for the client to push the results of identification/authentication. But in 1.0, we had a "stateless" claims collection system, and a parallel if somewhat poorly documented trust elevation system, the "stateful" AAT/authorization endpoint/ authentication_context hint system.

In 2.0 we have only the former. Between the AS and the client there is no special knowledge about any identification/authentication semantics, and the AS can only give hints about what kinds of claims it needs and nothing else.

So looking at the situation, a couple of options suggest themselves:

  1. No change to 2.0 as specified now: Either deployers express the authentication-related hints they want in claim-hint language or write an extension (in which case we might want to provide some examples along these lines).
  2. Add back authentication-related hints and somehow map them to the "stateless" world, possibly having to do this per claim token profile and not just generically. (In which case this issue relates to #263 https://github.com/KantaraInitiative/wg-uma/issues/263.)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/wg-uma/issues/264#issuecomment-271055067, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIeYZQkJCpteyduxFkCEr9ACNL_snSrks5rPvK0gaJpZM4LbL6l .

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

agropper commented 7 years ago

apologies for premature send...

In our HIE of One implementation the AS offers the RqP four options for authentication: (1) Direct: username and password at the AS (2) Institutional: the RS offers to act as an IDP as an option at resource registration time (3) Federated: the AS operator whitelists an IDP (4) Self-sovereign: the AS accepts a decentralized ID and verifiable claims

(2) is very important in healthcare where an institution wants to open access to the AS to all staff without much further scrutiny because the AS controls access to other RSs. This is a typical health information exchange situation.

(4) is being developed in Rebooting Web of Trust to support blockchain identity standards

All 4 of these are being demonstrated at https://www.youtube.com/watch?v=FNlAkGauIdw&list=PLn9P7BiqUmmjk09q4I57cvPwysvsScm1p&index=6

Adrian

On Fri, Jan 6, 2017 at 9:04 PM, Eve Maler notifications@github.com wrote:

In a "narrow" ecosystem, the AS would be the IdP. In a "medium" ecosystem, the AS can be a secondary audience for an ID token sent by the client as a claim through pre-established trust. (There are other patterns we've brought up in the past for the AS to be a claims client, such as "AS requests claims and client does act_as Bob to send them" http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-04-07?src=search, but at present that would be some sort of extension flow.) In a "wide" ecosystem where there is no pre-established trust, you wouldn't be able to trust a pushed claim in any of the traditional ID token/assertion systems I'm familiar with because of the audience challenge.

So...it's by no means impossible for the client to push the results of identification/authentication. But in 1.0, we had a "stateless" claims collection system, and a parallel if somewhat poorly documented trust elevation system, the "stateful" AAT/authorization endpoint/ authentication_context hint system.

In 2.0 we have only the former. Between the AS and the client there is no special knowledge about any identification/authentication semantics, and the AS can only give hints about what kinds of claims it needs and nothing else.

So looking at the situation, a couple of options suggest themselves:

  1. No change to 2.0 as specified now: Either deployers express the authentication-related hints they want in claim-hint language or write an extension (in which case we might want to provide some examples along these lines).
  2. Add back authentication-related hints and somehow map them to the "stateless" world, possibly having to do this per claim token profile and not just generically. (In which case this issue relates to #263 https://github.com/KantaraInitiative/wg-uma/issues/263.)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/wg-uma/issues/264#issuecomment-271055067, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIeYZQkJCpteyduxFkCEr9ACNL_snSrks5rPvK0gaJpZM4LbL6l .

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

nynymike commented 7 years ago

Eve, I'm ok with your option 1: no change to 2.0. I can live with the AS being the client/SP of the OP/SAML IDP. As Justin's sequence diagrams show, it satisfies at least both the narrow and medium ecosystem requirements.

jricher commented 7 years ago

+1 for option 1. I believe the current text is sufficient and login mechanics are a detail of the AS.

xmlgrrl commented 7 years ago

Thanks for the awesome WSDs, Justin.

xmlgrrl commented 7 years ago

This got discussed in the ad hoc continuance of UMA telecon 2017-01-12, though not concluded. We could be close to consensus. This is related to #254.

xmlgrrl commented 7 years ago

Hey @jricher, can I get the source for those swimlanes to possibly use one of them in the detailed UMA2 swimlane? Thanks!

jricher commented 7 years ago

It's already available from the above links by removing cgi-bin/cdraw/ from the URL (because of how WSD works) but I'll link it here directly:

https://www.websequencediagrams.com/?lz=dGl0bGUgVU1BIFN0ZXAgVXAgQXV0aGVudGljYXRpb24gd2l0aCBsb2NhbCB1c2VyCgpwYXJ0aWNpcGFudCBSZXNvdXJjZVxuU2VydmVyIGFzIHJzABYNQXV0aG9yaXoASQUAHAxhABoOQ2xpZW50IGFzIGMAVA9xdWVzdGluZ1xuUGFydHkAXwVxcAoKCmMtPnJzOgAaCCByAIEGByB3L28gdG9rZW4KcnMtPmFzOiByABwHdGlja2V0CmFzADQGcmV0dXJuAA4IcnMtPmMABg8gYW5kIEFTIHBvaW50ZXIKYwBBD29rZQCCHAcAUAthczogZXZhbHVhdGUgcG9saWN5XG5yZXF1aXJlcyBzdGVwLXVwIGF1dGhuAIEGBWM6IG5lZWRfaW5mbywgc2VuZCB0b1xuAG0FYWMAgwEFZW5kAH4FAIFvBXFwOiByZWRpcmVjdCB0byAAFBVycXAAgXYGZm9sbG93ACgJCnJxcDwtAIIRBmEAg2EKZSB0byBmdWxmaWxsAINoBwCBNAYAgicGAGMQYwCDKAYAhBgFbmV3AII6CXFwAII_BQBkEACBfTpScVAgaGFzAIIoBidkAIIoCACDMggAg2EFAIQBBwCDXQgAg30LAIQBBQ&s=napkin

https://www.websequencediagrams.com/?lz=dGl0bGUgVU1BIFN0ZXAgVXAgQXV0aGVudGljYXRpb24gd2l0aCBPSURDIGF1dGggY29kZQoKcGFydGljaXBhbnQgUmVzb3VyY2VcblNlcnZlciBhcyBycwAWDUF1dGhvcml6AE0FABwMYQAaDkNsaWVudCBhcyBjAFQPcXVlc3RpbmdcblBhcnR5AF8FcXAAew1JZGVudGl0eVxuUHJvdmlkAIEEBmlkcAoKYy0-cnM6AD8IIHIAgSsHIHcvbyB0b2tlbgpycy0-YXM6IHIAHAd0aWNrZXQKYXMANAZyZXR1cm4ADghycy0-YwAGDyBhbmQgQVMgcG9pbnRlcgpjAEEPb2tlAIJFBwBQC2FzOiBldmFsdWF0ZSBwb2xpY3lcbnJlcXVpcmVzIHN0ZXAtdXAAgnMFbgCBBgVjOiBuZWVkX2luZm8sIHNlbmQgdG9cbgBtBWFjAIMqBWVuZAB-BQCBbwVxcDogcmVkaXJlY3QgdG8gABQVcnFwAIF2BmZvbGxvdwAoCQoAgXgGADQQSWRQAIQFBSd6ADQPaWRwADIScnFwPC0AFQdhAIRPCmUAQwcKaWRwAIEYEACEbAUAhGIKAIEGGWFzAG0Hc3VibWl0AIUVCiBmb3IAg1AHAFoFAINSBgCDPAVhY2Nlc3MAgwcHYW5kIGlkAIN6BwCCfhIAEwgAg1UFbG9nIGluIFJxUACCABdjAIU1BgCGKQVuZXcAhCIJcXAAhCcFAIJMEACDZTpScVAgaGFzAIQQBidkAIQQCACFGggAhUkFAIVpBwCFRQgAhWULAIVpBQ&s=napkin

xmlgrrl commented 7 years ago

Thank you. :-)

xmlgrrl commented 7 years ago

This was reviewed during UMA telecon 2017-02-09 and okayed.