Authentication-related error details #264
Comments
xmlgrrl
added
core
|
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. |
|
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 Similarly, if a SAML IDP provides the federated authentication APIs, you'd need to send an authn request with the 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. |
|
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 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. |
|
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. |
|
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. |
|
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/ 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:
|
|
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 ***@***.***> 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
<#263>.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#264 (comment)>,
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/
|
|
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 ***@***.***>
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
> <#263>.)
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#264 (comment)>,
> 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/
|
|
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. |
|
+1 for option 1. I believe the current text is sufficient and login mechanics are a detail of the AS. |
|
Thanks for the awesome WSDs, Justin. |
|
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. |
|
Hey @jricher, can I get the source for those swimlanes to possibly use one of them in the detailed UMA2 swimlane? Thanks! |
|
It's already available from the above links by removing |
|
Thank you. :-) |
This isn’t a code example, but rather a paragraph’s worth of example text attached to the authorization process loop discussion.
|
This was reviewed during UMA telecon 2017-02-09 and okayed. |
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?
The text was updated successfully, but these errors were encountered: