CAS Protocol Milestone
Marvin Addison
marvin.addison at gmail.com
Fri Aug 15 10:06:14 EDT 2014
> I still need to review Tom's initial notes on the consent work, it might
> be a good idea to take a look at that with some CAS eyes.
Will do.
> we have to collapse location into identity and basically treat the return
> path as an effective identity to trigger off of.
That's how it works now and is consistent with the CAS protocol.
Anyone using CAS ought to understand the benefits and liabilities of
the security model, which is based on DNS. Even if there were
metadata, the only input into the metadata would be the service
parameter, so it adds nothing in terms of security. I do believe there
could be some benefit generally, for example custom principal
selection or rejecting requests from unknown parties, so we should
continue to consider CAS-specific metadata.
I should note that Daniel and I have discussed a "strong" ticket
validation that would require client SSL on the back-channel ticket
validation step to convey a certificate that would be an input into a
metadata repository to confirm relying party identity. That sort of
capability would effectively be a CAS protocol extension; in other
words, great idea that's not going to happen anytime soon.
> My personal feeling is that we either profile and implement metadata for
> this, which is quite easy, or we should treat the requests as Anonymous
> (and thus subject to that policy assumption for attribute release).
The requests simply aren't anonymous. There is an identity model,
albeit a weaker one than digital signatures or encryption. In terms of
functionality, we need the ability to filter attributes on the basis
of relying party ID. The anonymous policy simply isn't fine-grained
enough to accommodate the needs of existing CAS deployers.
> I'm assuming from the
> work that you've done that you're interested in at least assisting with
> support and maintenance?
Absolutely. I envision being the module maintainer for the foreseeable future.
> But if the maintenance story makes sense and if the alignment
> configuration/policy wise is sound, I don't have an objection as long as
> it doesn't impact our schedule. It could also just be a quick follow on
> 3.1 addition anyway.
Sounds good.
M
More information about the dev
mailing list