RE: [cas-user] multi valued attributes in CAS 2.0 protocol
From: William G. Thompson, Jr. [mailto:wgt...@gmail.com] Sent: Tuesday, October 22, 2013 9:18 AM Sorry I was clearer...the pointer to CAS-1283 was a more of a suggestion to engage on that ticket...presumably to incorporate your enhancements. Ah, okay; I updated the ticket with a comment indicating it currently does not handle multivalued attributes and included the sample code adding an additional loop to avoid flattening them out. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
Excellent. I've re-opened this issue to consider Paul's enhancement. On Wed, Oct 23, 2013 at 12:48 PM, Paul B. Henson hen...@csupomona.edu wrote: From: William G. Thompson, Jr. [mailto:wgt...@gmail.com] Sent: Tuesday, October 22, 2013 9:18 AM Sorry I was clearer...the pointer to CAS-1283 was a more of a suggestion to engage on that ticket...presumably to incorporate your enhancements. Ah, okay; I updated the ticket with a comment indicating it currently does not handle multivalued attributes and included the sample code adding an additional loop to avoid flattening them out. -- You are currently subscribed to cas-user@lists.jasig.org as: wgt...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
Sorry I was clearer...the pointer to CAS-1283 was a more of a
suggestion to engage on that ticket...presumably to incorporate your
enhancements.
Best,
Bill
On Fri, Oct 11, 2013 at 10:02 PM, Paul B. Henson hen...@csupomona.edu wrote:
From: William G. Thompson, Jr. [mailto:wgt...@gmail.com]
Sent: Friday, October 11, 2013 5:36 PM
You'll want to take a look at this: https://issues.jasig.org/browse/CAS-1283
That code looks suspiciously similar to the code on the wiki; I don't really
see how that would not also flatten out multivalued attributes into a comma
separated list as opposed to enumerating them separately?
I guess the jsp foreach is smart enough to do the right thing if you give it
just a simple string rather than a collection, as:
c:forEach var=attr
items=${auth.principal.attributes}
c:forEach var=attrval
items=${attr.value}
cas:${fn:escapeXml(attr.key)}${fn:escapeXml(attrval)}/cas:${fn:escapeXml(attr.key)}
/c:forEach
/c:forEach
seems to do what I want:
cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'
cas:authenticationSuccess
cas:userhenson/cas:user
cas:attributes
cas:snHenson/cas:sn
cas:givenNamePaul/cas:givenName
cas:csupomonaEduPersonAffiliationeoc_essential/cas:csupomonaEduPersonAffiliation
cas:csupomonaEduPersonAffiliationemployee/cas:csupomonaEduPersonAffiliation
cas:csupomonaEduPersonAffiliationmember/cas:csupomonaEduPersonAffiliation
cas:csupomonaEduPersonAffiliationstaff/cas:csupomonaEduPersonAffiliation
/cas:attributes
/cas:authenticationSuccess
/cas:serviceResponse
And yay, ezproxy successfully parses this...
--
You are currently subscribed to cas-user@lists.jasig.org as: wgt...@gmail.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
Hi folks, Just my 2 cents : With my experience it's really easy to share user attributes over SAML than with the jsp, why ? until now each CAS deployer tried to use the jsp to share user attributes but every one made his jsp code and so there is a lot of schema attributes sharing over this method, whereas SAML there is only normalized way for attributes sharing. More it's compatible with shibboleth attributes release, so you don't have to delopp each times a CAS client when using the SAML (event if CAS client exists there is a lot of langages where there isn't CAS client). Also the only thing missing with CAS 3.x version is the attributes release in proxy mode with SAML schema. After the SAML is a good practice to enforce the security in flows (but only when it's needed), and for that shibboleth use it with efficience. More the php and java CAS client are compatible with SAML attributes sharing ! I'm seeing the service validate (using jsp) as only a simple service to validate user access, and the SAML service validate as an evolved service needed to release user attributes in a normalized way. In my mind providing a normlized way for attribute sharing is realluy needed, I'm not sure that the jsp is a good way, there are several ways to share attributes more using libraries, even in json, but sharing a normalized way for attributes sharing with shibboleth can provide a good point to CAS ;) My experience is based on communication with several external ressources editors, they have to set several CAS client to access to their services, and so they have to configure a different client and due to CAS using only jsp to release attributes they have a lot of problem to integrate new services due to lack of schema normalization, and more if they has to developp a specific client it's always a pain to integrate quickly the service, but when we say that they can use the SAML this is always welcome and really fastest to integrate services when attributes sharing are needed. And sorry for my poor english this morning ! Regards, Julien Gribonvald Le 11/10/2013 22:30, William G. Thompson, Jr. a écrit : On Fri, Oct 11, 2013 at 2:08 PM, Marvin S. Addison marvin.addi...@gmail.com wrote: Hmm, that's the impression I got after a meeting with Unicon, perhaps I misunderstood them. I believe Unicon steers folks away from SAML. I understand you to mean /cas/samlValidate here rather than SAML, but just to be clear, Unicon does not steer folks away from SAML. In fact, Unicon has a healthy and growing practice around SAML and Shibboleth in particular. Best, Bill -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
My understanding was that despite it being the official mechanism, SAML is for the most part deprecated Absolutely not. It may be deprecated at some (distant) future date, but many folks are happily using the SAML support in many clients for attribute release. No server or client customizations needed. most people are extending the CAS 2.0 protocol to supply attributes rather than using SAML I don't think we have any numbers. I'd be happy to start a thread asking for folks to speak up to get a sense, but from past experience it's hard to gauge accurately with self reporting. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
From: Marvin S. Addison [mailto:marvin.addi...@gmail.com] Sent: Friday, October 11, 2013 6:35 AM Absolutely not. It may be deprecated at some (distant) future date, but many folks are happily using the SAML support in many clients for attribute release. No server or client customizations needed. Hmm, that's the impression I got after a meeting with Unicon, perhaps I misunderstood them. In any case, it looks like the client I'm trying to get to work (ezproxy) doesn't support SAML :(, so I'm stuck with unofficial CAS 2.0 attributes. Did you by any chance have the opportunity to look at the other email I sent on this subject as far as whether or not the variable within the jsp file has already been flattened, or if there is the potential to tweak the jsp to iterate over it and generate separate entries for each value rather than flatten it? Thanks much... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
Hmm, that's the impression I got after a meeting with Unicon, perhaps I misunderstood them. I believe Unicon steers folks away from SAML. I believe it's motivated in some cases by the need to support proxying with attribute release, which SAML 1.1 does not support. If they used the word deprecated, then that would be incorrect. It's supported now and for the foreseeable future. In any case, it looks like the client I'm trying to get to work (ezproxy) doesn't support SAML :(, so I'm stuck with unofficial CAS 2.0 attributes. Understood. Did you by any chance have the opportunity to look at the other email I sent on this subject as far as whether or not the variable within the jsp file has already been flattened, or if there is the potential to tweak the jsp to iterate over it and generate separate entries for each value rather than flatten it? You mean this: cas:attributes cas:csupomonaEduPersonAffiliation[a, b, c]/cas:csupomonaEduPersonAffilication /cas:attributes I admit that doesn't look correct but I'm not certain. What reference did you follow for customizing the casServiceValidationSuccess.jsp file? M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
Hey Paul, Since you brought up the Unicon meeting I figure I'll just respond here in this thread. Sorry if I gave you the wrong impression regarding the official status of /cas/samlValidate. The point I was making was that /cas/samlValidate was essentially superseded by the 3.0 protocol spec rev (and the CAS 4.0 release) that was catching up to broader community practice regarding releasing attributes in /cas/serviceValidate. /cas/samlValidate simply sends a SAML1 document back in response to a ST validate request. It never really achieved any general interoperability with other SAML entities. Therefore one can view this particular feature as CAS specific implementation detail rather than SAML support. This thread might be of some help with OCLC. https://groups.google.com/forum/#!topic/jasig-cas-user/QsW2eeA6WYw Best, Bill On Fri, Oct 11, 2013 at 1:56 PM, Paul B. Henson hen...@csupomona.edu wrote: From: Marvin S. Addison [mailto:marvin.addi...@gmail.com] Sent: Friday, October 11, 2013 6:35 AM Absolutely not. It may be deprecated at some (distant) future date, but many folks are happily using the SAML support in many clients for attribute release. No server or client customizations needed. Hmm, that's the impression I got after a meeting with Unicon, perhaps I misunderstood them. In any case, it looks like the client I'm trying to get to work (ezproxy) doesn't support SAML :(, so I'm stuck with unofficial CAS 2.0 attributes. Did you by any chance have the opportunity to look at the other email I sent on this subject as far as whether or not the variable within the jsp file has already been flattened, or if there is the potential to tweak the jsp to iterate over it and generate separate entries for each value rather than flatten it? Thanks much... -- You are currently subscribed to cas-user@lists.jasig.org as: wgt...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
From: Marvin S. Addison [mailto:marvin.addi...@gmail.com]
Sent: Friday, October 11, 2013 11:08 AM
You mean this:
cas:attributes
cas:csupomonaEduPersonAffiliation[a, b,
c]/cas:csupomonaEduPersonAffilication
/cas:attributes
No, I meant the post containing the underlying jsp code that generated it:
c:forEach var=attr items=${auth.principal.attributes}
cas:${fn:escapeXml(attr.key)}${fn:escapeXml(attr.value)}/cas:${fn:escapeXml(attr.key)}
/c:forEach
This code does appear to generate one entry for each attribute, containing
whatever attr.value is. My curiosity is whether the attr.value variable is a
collection at this point in the jsp, and the escapeXml call is what is
flattening it (in which case the jsp could potentially be modified to detect it
is a collection and do an additional foreach to break them out separately) or
if the variable attr.value is already flattened by the time the jsp sees it, in
which case it would need to be fixed somewhere else.
I admit that doesn't look correct but I'm not certain. What reference
did you follow for customizing the casServiceValidationSuccess.jsp file?
I copied it from the wiki:
https://wiki.jasig.org/display/CASUM/Attributes
Thanks...
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
The point I was making was that /cas/samlValidate was essentially superseded by the 3.0 protocol spec rev (and the CAS 4.0 release) that was catching up to broader community practice regarding releasing attributes in /cas/serviceValidate. I would say we're planning to support _both_ the existing SAML 1.1 capability and the new CAS 3.0 protocol. I'm not aware of any plan to supersede one for the other at present, though it's entirely possible that may happen in the future. It's simply a fact that CAS 3.0 will be able to do everything that the SAML 1.1 support offers and more. On the topic of broader community practice, do you have any numbers? I mentioned interest in adoption numbers in the thread previously, and if you have some data it would be helpful to share. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
From: William G. Thompson, Jr. [mailto:wgt...@gmail.com] Sent: Friday, October 11, 2013 11:51 AM Since you brought up the Unicon meeting I figure I'll just respond here in this thread. Sorry if I gave you the wrong impression regarding the official status of /cas/samlValidate. Possibly I misunderstood you; the question was more or less whether most applications would do samlValidate and I didn't need to worry about the custom jsp extension, or if most applications only worked with CAS 2.0 attribute extensions, and the rough answer was more or less the latter. Which, at least in the case of ezproxy, seems to be true so far :). This thread might be of some help with OCLC. https://groups.google.com/forum/#!topic/jasig-cas-user/QsW2eeA6WYw Yeah, that looks like basically what I'm doing. The ezproxy client sees the attributes being returned by the custom jsp with no problem, it's just that multi valued attributes are getting flattened out into a single value which is less than ideal. And that's definitely on the CAS side, not the ezproxy side, as can be seen in the returned XML. Thanks... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
On Fri, Oct 11, 2013 at 2:08 PM, Marvin S. Addison marvin.addi...@gmail.com wrote: Hmm, that's the impression I got after a meeting with Unicon, perhaps I misunderstood them. I believe Unicon steers folks away from SAML. I understand you to mean /cas/samlValidate here rather than SAML, but just to be clear, Unicon does not steer folks away from SAML. In fact, Unicon has a healthy and growing practice around SAML and Shibboleth in particular. Best, Bill -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
I understand you to mean /cas/samlValidate here rather than SAML, That's exactly what I meant. Only with respect to attribute release in CAS. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
No, I meant the post containing the underlying jsp code that generated it:
c:forEach var=attr items=${auth.principal.attributes}
cas:${fn:escapeXml(attr.key)}${fn:escapeXml(attr.value)}/cas:${fn:escapeXml(attr.key)}
/c:forEach
Missed that. That JSP code absolutely will not work with the attribute
parsing code in phpCAS HEAD revision. Here's the source for the
parsing code [1]:
/**
* This method will parse the DOM and pull out the attributes from the XML
* payload and put them into an array, then put the array into the session.
*
* @param string $success_elements payload of the response
*
* @return bool true when successfull, halt otherwise by calling
* CAS_Client::_authError().
*/
private function _readExtraAttributesCas20($success_elements)
{
phpCAS::traceBegin();
$extra_attributes = array();
// Jasig Style Attributes:
//
// cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'
// cas:authenticationSuccess
// cas:userjsmith/cas:user
// cas:attributes
// cas:attraStyleRubyCAS/cas:attraStyle
// cas:surnameSmith/cas:surname
// cas:givenNameJohn/cas:givenName
// cas:memberOfCN=Staff,OU=Groups,DC=example,DC=edu/cas:memberOf
// cas:memberOfCN=Spanish
Department,OU=Departments,OU=Groups,DC=example,DC=edu/cas:memberOf
// /cas:attributes
//
cas:proxyGrantingTicketPGTIOU-84678-8a9d2sfa23casd/cas:proxyGrantingTicket
// /cas:authenticationSuccess
// /cas:serviceResponse
//
I think the comment makes it pretty clear the expected XML format,
which matches my recollection. You'll need an inner loop to unroll
attribute values that contain collections.
M
[1] https://github.com/Jasig/phpCAS/blob/master/source/CAS/Client.php
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
You'll want to take a look at this: https://issues.jasig.org/browse/CAS-1283 Best, Bill On Fri, Oct 11, 2013 at 8:16 PM, Paul B. Henson hen...@csupomona.edu wrote: From: Marvin Addison [mailto:marvin.addi...@gmail.com] Sent: Friday, October 11, 2013 1:40 PM Missed that. That JSP code absolutely will not work with the attribute parsing code in phpCAS HEAD revision. Here's the source for the That's an annoying inconsistency, given that piece of the wiki describing the jsp modification is entitled Accessing attributes using phpCAS ;). I think the comment makes it pretty clear the expected XML format, which matches my recollection. You'll need an inner loop to unroll attribute values that contain collections. It sounds like the jsp has access to the un-flattened collection then, so I guess if nobody on the list who writes jsp in their sleep steps up, I'll go hack at it... Thanks... -- You are currently subscribed to cas-user@lists.jasig.org as: wgt...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
And this one: https://issues.jasig.org/browse/CAS-1284 On Fri, Oct 11, 2013 at 8:36 PM, William G. Thompson, Jr. wgt...@gmail.com wrote: You'll want to take a look at this: https://issues.jasig.org/browse/CAS-1283 Best, Bill On Fri, Oct 11, 2013 at 8:16 PM, Paul B. Henson hen...@csupomona.edu wrote: From: Marvin Addison [mailto:marvin.addi...@gmail.com] Sent: Friday, October 11, 2013 1:40 PM Missed that. That JSP code absolutely will not work with the attribute parsing code in phpCAS HEAD revision. Here's the source for the That's an annoying inconsistency, given that piece of the wiki describing the jsp modification is entitled Accessing attributes using phpCAS ;). I think the comment makes it pretty clear the expected XML format, which matches my recollection. You'll need an inner loop to unroll attribute values that contain collections. It sounds like the jsp has access to the un-flattened collection then, so I guess if nobody on the list who writes jsp in their sleep steps up, I'll go hack at it... Thanks... -- You are currently subscribed to cas-user@lists.jasig.org as: wgt...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
From: William G. Thompson, Jr. [mailto:wgt...@gmail.com]
Sent: Friday, October 11, 2013 5:36 PM
You'll want to take a look at this: https://issues.jasig.org/browse/CAS-1283
That code looks suspiciously similar to the code on the wiki; I don't really
see how that would not also flatten out multivalued attributes into a comma
separated list as opposed to enumerating them separately?
I guess the jsp foreach is smart enough to do the right thing if you give it
just a simple string rather than a collection, as:
c:forEach var=attr
items=${auth.principal.attributes}
c:forEach var=attrval
items=${attr.value}
cas:${fn:escapeXml(attr.key)}${fn:escapeXml(attrval)}/cas:${fn:escapeXml(attr.key)}
/c:forEach
/c:forEach
seems to do what I want:
cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'
cas:authenticationSuccess
cas:userhenson/cas:user
cas:attributes
cas:snHenson/cas:sn
cas:givenNamePaul/cas:givenName
cas:csupomonaEduPersonAffiliationeoc_essential/cas:csupomonaEduPersonAffiliation
cas:csupomonaEduPersonAffiliationemployee/cas:csupomonaEduPersonAffiliation
cas:csupomonaEduPersonAffiliationmember/cas:csupomonaEduPersonAffiliation
cas:csupomonaEduPersonAffiliationstaff/cas:csupomonaEduPersonAffiliation
/cas:attributes
/cas:authenticationSuccess
/cas:serviceResponse
And yay, ezproxy successfully parses this...
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
What is the unofficial official way of handling attributes in the CAS 2.0 protocol? I honestly don't know. The official mechanism for attribute release is via the SAML 1.1 protocol. Attribute release will be officially supported in the CAS 3.0 protocol spec: https://github.com/Jasig/cas/blob/master/cas-server-protocol/3.0/cas_protocol_3_0.md I can't speak to various client support for the 2.0 protocol extension since we don't use it. I understand many folks do use it, so they can speak to client support. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] multi valued attributes in CAS 2.0 protocol
On Oct 10, 2013, at 6:18 AM, Marvin S. Addison marvin.addi...@gmail.com wrote: What is the unofficial official way of handling attributes in the CAS 2.0 protocol? I honestly don't know. The official mechanism for attribute release is via the SAML 1.1 protocol. Attribute release will be officially supported in the CAS 3.0 protocol spec: https://github.com/Jasig/cas/blob/master/cas-server-protocol/3.0/cas_protocol_3_0.md I can't speak to various client support for the 2.0 protocol extension since we don't use it. I understand many folks do use it, so they can speak to client support. The attribute string [ foo, bar, baz ] looks suspiciously like the result of a toString() on a collection. Both flavors of SAML represent attributes as roughly: Attributes Attribute name=... type=... Valuefoo/Value Valuebar/Value ... /Attribute ... /Attributes Following SAML on-the-wire attributes (cf. registered OIDs) would avoid having to invent new ad-hoc representations, e.g. cas:title, cas:firstname, etc. though, admittedly, at the expense of readability (perhaps explaining why SAML 2.0 introduced attribute 'friendly' names). Tom. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
From: Marvin S. Addison [mailto:marvin.addi...@gmail.com] Sent: Thursday, October 10, 2013 6:18 AM I honestly don't know. The official mechanism for attribute release is via the SAML 1.1 protocol. Attribute release will be officially supported in the CAS 3.0 protocol spec: My understanding was that despite it being the official mechanism, SAML is for the most part deprecated, and most people are extending the CAS 2.0 protocol to supply attributes rather than using SAML. I'd like to get the server to do what the average client is going to want :)... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
From: Tom Poage [mailto:tfpo...@ucdavis.edu]
Sent: Thursday, October 10, 2013 8:30 AM
The attribute string [ foo, bar, baz ] looks suspiciously like the result
of a
toString() on a collection.
The jsp code on the wiki:
c:forEach var=attr items=${auth.principal.attributes}
cas:${fn:escapeXml(attr.key)}${fn:escapeXml(attr.value)}/cas:${fn:escapeXml(attr.key)}
/c:forEach
does look like it pretty much spits out cas:namevalue/cas:name, I'm not
that familiar with jsp, is it likely that attr.value is a collection, being
converted to a string? In which case perhaps the jsp could be modified to
detect that it is a collection and do another foreach to split it up and write
out each value separately rather than concatenated? Or is it more likely that
attr.value is already a flattened out string when it is referenced in the jsp?
Both flavors of SAML represent attributes as roughly:
Well, in this case that only matters if the average CAS 2.0 attribute extended
client likes them that way :). Looking at the php CAS client, it accepts a
variety of different attribute encodings, none of which seem to match the
example on the wiki as far as how to enable it on the server-side 8-/...
Thanks...
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
