Am 02.09.2011 04:39, schrieb Andrew Petro:
> since it's only a "known extension" but not officially supported
Thoughts on promoting this to be an officially supported
/cas3validate
validation endpoint?
Possibly with authentication of the validating service by TLS so as to
be able to authenticate the request for attributes and even eliminate
the proxy callback?
Possibly adding an "acceptProxyTickets" URL parameter, defaulting to
false, so that client libraries and integrators can better understand
the opportunity to opt in to accepting proxy tickets and are less likely
to do it if they don't mean it?
SAML's complicated. An enrichened CAS2-protocol-style endpoint is
simpler and to the point. If Joachim and others are always extending the
CAS validation responses anyway to meet your needs, if integrating
vendors expect adopters to extend the CAS validation response to meet
this ened, then maybe it's time to slurp this up into the product and
make it better specified and official so that vendors like OCLC have a
richer (and more standard) integration surface to work with.
Thoughts?
Andrew
This the issue is partly due to that fact that SAML support itself is
pretty "young", not so many applications support it out of the box and
the advertising is not been optimal.
This made it much easier to extend the cas server answer and just add
some minimal code to client that do/did not support SAML yet. As you
have also mentioned it a very simple xml code so pretty much everyone
can do that themselve in any language.
Another big issue that i have always seen is that in big installations
you always have a few proxy apps that also want attributes. Since SAML
doesn't do proxy you are either stuck with proxy that does cas id + LDAP
lookup which creates a lot of problems in my view. In a decentralized
environment (you)i don't want to hand out LDAP lookup accounts and at
least for me the attribute release has also always been a privacy tool
to protect the users privacy. I can limit what app can see which
attributes without the hassle to create accounts, monitor usage and
limit misusage of ldap. People tend to misappropriate data sources one
you give the access. It also solves some data privacy issue or at least
gives the user a chance to limit themselve who gets their private data
(checkbox: Warn me me before logging in somewhere else). This get's more
interesting once the borders of your installation get fuzzy (domain,
partner sites, no corporate identity sites, pure user perception) and
the services gets in the hundreds...
I myself am pretty much a fan of officials standards. This is why i
always advertise SAML 1.1 whenever possible and i would really like the
SAML 2.0 or similar development to go ahead. Another self designed
protocol would not be my first choice. I personally see much better
support for applications if we go down with SAML 2.0 since a lot more
other projects are going that way. Might be wrong there...
The hacks where simply born out of urgent needs that could not be
catered by the current protocols of cas and it was simply to easy to
hack this really simple fix the cure the immediate need.
Adding this minor extension to the official protocol extension cas 2.1?
as an immediate fix (maybe commented out as optional) would probably
solve some of the user confusions in that area. Just a crazy thought ;)
Regards,
Joachim
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
