[Openid-specs-fastfed] FW: Question about 7.2.4 (Handshake Finalization)

McAdams, Darin darinm at amazon.com
Fri Oct 18 21:27:40 UTC 2019


(Forwarding on behalf of Wes while awaiting permissions to the mailing list.)

From: Wesley Dunnington <wesleydunnington at pingidentity.com>
Date: Friday, October 18, 2019 at 1:29 PM
To: Brian Rose <brian.rose at sailpoint.com>
Cc: "McAdams, Darin" <darinm at amazon.com>, Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
Subject: Re: [Openid-specs-fastfed] Question about 7.2.4 (Handshake Finalization)

 As was mentioned, the JWT that the identity provider sent to the application provider for the registration request in 7.2.3.1 contains the IDP domain and the tenant ID of the application provider. The most straightforward option would be to re-send the initial JWT to the finalization endpoint. Alternatively the IDP could generate a cut-down JWT with just the IDP domain and the tenant id.

With regards to returning failure to the finalize URL, I had been of the opinion that since by that point the entire configuration had been agreed on by the IDP and Application provider, that the onus would be on the IDP to fix things and roll forward if it had a problem, calling /finalize when it was able to do so. If the IDP returned failure at this point it would seem to me to indicate some sort of serious internal failure. If so I would imagine the logical course would be to declare the entire federation in error and restart the entire handshake over.

Wes Dunnington

Wes Dunnington

On Fri, Oct 18, 2019 at 2:05 PM Brian Rose via Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>> wrote:
Yes, that would be great.  Would there be any other information returned in the payload?  Or is it going to be just enough for the AP finalize call to know the issuer and tenant?  At an absolute minimum, “iss” and “sub” are what I would need.

Also, related to the payload, section 7.2.4 states “the Identity Provider MUST invoke this endpoint after successfully processing…”.  Should the finalize endpoint ALWAYS get called, even if there is an error somewhere in the handshake?  If so, it might be nice for it to have some error information so the AP knows that the IdP will no longer be attempting.  Or, after 48 hours (or whatever the retry span is), that it was ultimately unsuccessful and what the corresponding error was.

Thanks,

Brian Rose
Staff Software Engineer
brian.rose at sailpoint.com<mailto:brian.rose at sailpoint.com>
www.sailpoint.com<http://www.sailpoint.com>
From: McAdams, Darin <darinm at amazon.com<mailto:darinm at amazon.com>>
Sent: Wednesday, October 16, 2019 6:19 PM
To: Brian Rose <brian.rose at sailpoint.com<mailto:brian.rose at sailpoint.com>>; openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>
Subject: Re: [Openid-specs-fastfed] Question about 7.2.4 (Handshake Finalization)

Good catch. Would it help if a signed JWT came along in this request as well?

From: Openid-specs-fastfed <openid-specs-fastfed-bounces at lists.openid.net<mailto:openid-specs-fastfed-bounces at lists.openid.net>> on behalf of Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>>
Reply-To: Brian Rose <brian.rose at sailpoint.com<mailto:brian.rose at sailpoint.com>>
Date: Thursday, October 10, 2019 at 11:12 AM
To: Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>>
Subject: [Openid-specs-fastfed] Question about 7.2.4 (Handshake Finalization)

Hey all,

In my current POC implementation, I am attempting to set a flag to indicate that the full round trip has been completed in the finalization step.  How does the Application Provider know the provider domain and the tenant id so that it can verify that it has been previously whitelisted and update any associated data that the Application Provider might want to log?  During the registration, the JWT contains all of the necessary information to do the look up.  Also, as a result, is that this endpoint is wide open.

Thanks!
Brian Rose
SailPoint
_______________________________________________
Openid-specs-fastfed mailing list
Openid-specs-fastfed at lists.openid.net<mailto:Openid-specs-fastfed at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-fastfed


--
[Image removed by sender. Ping Identity]<https://www.pingidentity.com/>

Wesley Dunnington
Field CTO East Region
508-254-5475
wesleydunnington at pingidentity.com<mailto:wesleydunnington at pingidentity.com>




Connect with us:

[Image removed by sender. Glassdoor logo]<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[Image removed by sender. LinkedIn logo]<https://www.linkedin.com/company/21870>[Image removed by sender. twitter logo]<https://twitter.com/pingidentity>[Image removed by sender. facebook logo]<https://www.facebook.com/pingidentitypage>[Image removed by sender. youtube logo]<https://www.youtube.com/user/PingIdentityTV>[Image removed by sender. Blog logo]<https://www.pingidentity.com/en/blog.html>


[Image removed by sender.]<https://www.pingidentity.com/en/events/d/identify-2019.html>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20191018/d3531baf/attachment-0001.html>


More information about the Openid-specs-fastfed mailing list