Hi Sam,
First, a few questions - how would these error messages be signalled -
inside the Reply-Message in the access reject? Would this be configured in
the IdP - adding custom text to the Reply Message based on what happened?
Would people have to add this config themselves (I.e. We provide stuff to
copy and paste into their FR config), or we get it added to the FR
distribution with the abfab stuff so they don’t have to?
Anyway, I agree with Alejandro’s points, caveat your responses. Those,
with some of my own thoughts, leaves me with the following main non Trust
Router related things:
* Successfully reached IdP and successfully authenticated, but the IdP
will not authorise the user for that particular service so is access
rejecting (is it possible to do that on the IdP?).
* Successfully reached IdP, but failed authentication (without going into
detail why for security/privacy reasons)
* Couldn’t reach IdP - trust path exists but the AAA server didn’t respond
* Couldn’t reach IdP - no trust path could be found in this COI
And beyond that, yes, more detailed Trust Router errors would be good,
such as TR down, expired credentials, etc.
Also agree with Alejandro about authorisation at the RP failing should
bubble through somehow to the user, but that’s a different question
entirely to this one I think.
Rhys.
On 04/02/2015 12:28, "Sam Hartman" <[log in to unmask]> wrote:
>Thanks this is exactly the sort of advice I was looking for and is very
>well reasoned.
>
>I have a couple of minor notes:
>
>
>Note that IDP not in the COI manifests as cannot reach IDP.
>No trust path will exist withing the context of that COI.
>
>The RP chooses the COI it wants to request in. An RP that requests in a
>COI it's not a member of is going to have a disappointing existence.
>
>
>
>Also, I realize that I don't think the trust router protocol gives back
>a numeric result other than success and failure. I don't know if we'll
>end up fixing that in this pass but it seems clear from your message
>that we do want to fix that.
>
>--Sam
|
