Subject Canonicalization problem

Cantor, Scott cantor.2 at osu.edu
Mon Nov 9 11:09:55 EST 2015


On 11/9/15, 10:25 AM, "users on behalf of Michael A Grady" <users-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:



>I was thinking of error handling, and what would be appropriate to do here? If the above didn't succeed in delivering an actual value, what should one do?

It depends what condition you’re talking about. If you know what the authentication process is going to give you, then you can treat the absence of the right Principal is just a sanity check. If there are legitimate reasons for it to fail, I guess it just depends what that means in any particular deployment.

> Theoretically, you have Simple to still fall back on, and its own error handling if that doesn't succeed, but presumably it is going to try and access the same value as this.

Yes, that particular example is the same.

> And there is the matter of the data connector dependent on this Scripted attribute and what it's error behavior would be if no attribute. Any recommendations?

Usually a connector would return no data and it would be configurable there what you wanted it to do.

>On the other hand, you could argue that would be like just automatically running the Simple flow, but then giving a chance to override that choice by immediately trying a different flow.

Simple doesn’t really do anything, and once it runs you could never run anything else, it’s going to produce a result if a UsernamePrincipal is found.

> The downside to that, I guess, is that if that follow-on fails, you don't then have Simple to fall back on. (Maybe Simple becomes an optional "initial c14n flow", analogous to the "initial authn flow", that one can configure? For that matter, could one do that now with just a bit of c14n flow configuration, and not fall back on defining a scripted attribute/data connector dependent on that?)

I don’t know what you’re suggesting.

— Scott



More information about the users mailing list