> 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
On 9/1/2011 2:28 PM, Joachim Fritschi wrote:
You can either use SAML which will return attributes by default if the
properly configured [1] or use the unofficual extension of the cas 2.0
protocol.
If you want attributes in a cas 2.0 answer you have to extern the jsp
that returns the data. Details of possible modifications can be found in
a jira issue [2]
I have personally always extended the casServiceValidationSucccess.jsp
by adding the attributes right after the</cas:user> in the jsp (it's
pretty much the same as described in the jira issue with minor differences):
<cas:attributes>
<c:forEach var="attr"
items="${assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.attributes}">
<cas:${fn:escapeXml(attr.key)}>${fn:escapeXml(attr.value)}</cas:${fn:escapeXml(attr.key)}>
</c:forEach>
</cas:attributes>
This works with the official java client and the phpCAS client. I'm not
sure if any other client supports it since it's only a "known extension"
but not officially supported.
I have seen a few other ways of returning attributes and so far we have
added autodetection for 3 ways of attributes in phpCAS. There is some
code docs around the different formats we have found in the wild that
where requested by users to be added.[3]
I have attached a full version of a jsp i have been using. From my
personal experience i would personally also advise you to add and "xml
header" with UTF-8 encoding to the jsp that is sent to the client if
your are using attributes. I added it since attributes especially here
in europe tend to include umlauts, accents and other crazy stuff ;) that
may get mangled if the client on the other side is left alone with
guessing an encoding. Might not be needed for you but you never know...
I have not seen any issues with that for other clients. Encoding issues
could also depend on the source encoding of your attributes. Just be
aware that you should do some tests around that issue or be sure not to
have any special chars.
Regards,
Joachim
[1] https://wiki.jasig.org/display/CASUM/Attributes
[2] htttp://www.ja-sig.org/issues/browse/CAS-655
[3]
http://downloads.jasig.org/cas-clients/php/current/docs/api/Client_8php_source.html#l02690
Am 01.09.2011 18:52, schrieb Cary, Kim:
Thanks, Scott.
Can all the clients using serviceValidate consume the customized JSP or
will some possibly choke on it?
Anyone out there using such a custom JSP?
On Sep 1, 2011, at 9:43 AM, Scott Battaglia wrote:
By default /serviceValidate will NEVER said attributes back.
It requires a custom JSP.
On Thu, Sep 1, 2011 at 12:38 PM, Cary, Kim<[email protected]
<mailto:[email protected]>> wrote:
Going a little nuts here. We have a working EZProxy integration
with CAS. We're trying to do authorization based on attributes
that are returned by CAS, but EZProxy is only sending us
/serviceValidate ticket checks.
The OCLC support folks are saying that we just don't know how to
configure our CAS server to return those attributes. I'm saying
they must have developed it against some customized/extended CAS
server, because what they're sending us will NEVER result in an
attribute return.
Who is right? (or some other explanation)
Is anyone using EZProxy with group authorization by CAS attributes?
--
You are currently subscribed to [email protected]
<mailto:[email protected]> as: [email protected]
<mailto:[email protected]>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed
[email protected]<mailto:[email protected]>
as:[email protected]<mailto:[email protected]>
To unsubscribe, change settings or access archives,
seehttp://www.ja-sig.org/wiki/display/JSG/cas-user
--
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
--
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
