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
Is the Group-search-base supposed to stop at an OU? I took mine all
the way to the CN of the group. If it is supposed to stop at the OU
level, then how does Spring identify the right group?
That question drew me to what looks like an obvious problem in your config:
group-search-base=CN=CAS
where do I tell it what the group name is?
In the query string: (((objectclass=group)(cn=CAS ServiceMgmt
Access)(member={0})))
Best regards,
--
Carlos.
-Original Message-
From: Whittaker, Geoffrey [mailto:geoff.whitta...@unf.edu]
Sent: Friday, 11 October, 2013 13:31
To:
When I used a filter string like that, the application throws an exception as
soon as I start tomcat. I can't have the Ampersand in the
deployerconfigcontext file.
Geoff
-Original Message-
From: Carlos Fernandez [mailto:cfern...@sju.edu]
Sent: Friday, October 11, 2013 1:34 PM
To:
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
In XML files, as well as HTML files, you have to URL-encode the ampersand
as amp;, so
(((objectclass=group)(cn=CAS ServiceMgmt Access)(member={0})))
Becomes
((amp;(objectclass=group)(cn=CAS ServiceMgmt Access)(member={0})))
In deployerConfigContext.xml.
Best regards,
--
Carlos.
When I used a filter string like that, the application throws an
exception as soon as I start tomcat. I can't have the Ampersand in
the deployerconfigcontext file.
You need to use an XML escape character:
((amp;objectclass=group)(...))
M
--
You are currently subscribed to
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
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
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
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
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
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
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
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
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
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
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
18 matches
Mail list logo
