2010-6-24 MFA call
Non proxy use case
MFA but no proxying.Â
Outstanding Issue
- discussion of whether client gets authN type information returned (because these attributes can be used for authZ) or whether using service registry only is sufficient
- CAS 2 protocol allows additional error codes - extending these does not change protocol so this appears to be optimal.
- resolution? New service registry config required. New error codes will be returned but client does not have to notice them. A new client would be able to distinguish more errors and respond differently.
Multiple Proxies
- Discussion of whether tracking failure should be done all on server or with callbacks to the client (could reuse PGT callback). Reusing PGT call back is architecturally not good.
- general preference for server side tracking. To get reasonable user experience this still requires top level proxy to get some indication of failure back from it's proxy call.
Possible Blocks of Work
- Design service registry extensions and
- Design protocol changes for non proxying - error messages
- Design protocol changes for proxying
- Design CAS objects needed to track chained failure
What Multi-factor requirements to we want to support?
Let's pick up with this as our next agenda. The goal is to understand the requirements well enough to design a pluggable interface rather than go into detail for each.