Re: [cas-user] [cas-announce] CAS v.4.0.3 is released

[Jérôme LELEU]

Hi,

There are default values for these placeholders so you shouldn't have any
error (${propertyname:defaultvalue}). What's your error?

Thanks.
Best regards,
Jérôme


2015-08-05 6:13 GMT+02:00 Batni, Sourabh :

>
> --
> *From:* Batni, Sourabh
> *Sent:* Tuesday, August 4, 2015 2:28 PM
> *To:* Misagh Moayyed; cas-annou...@lists.ja-sig.org
> *Subject:* RE: [cas-announce] CAS v.4.0.3 is released
>
>
> Hi Misagh
>
>
>
> After I updated the cas.version in pom.xml to 4.0.3 from 4.0.1 the war
> file failed to deploy on tomcat and I was getting errors relating to
> characterEncodingFilter in
> filters.xml(WEB-INF/spring-configuration/filters.xml) on further looking
> into the file and comparing it with the version which was working(4.0.1) it
> looks like it is failing to load  some properties (
> *httprequest.web.encoding:UTF-8* and *httprequest.web.encoding.force:true*)
> in this file. Below are the 2 versions the first one is the one which has
> the problem (4.0.3) and the second one is from 4.0.1.
>
>
>
> I haven’t changed anything else and use the same script to build both of
> them,
>
>
>
> http://www.springframework.org/schema/beans";
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
>xmlns:p="http://www.springframework.org/schema/p"; xmlns:aop="
> http://www.springframework.org/schema/aop";
>
>xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd";>
>
>  class="org.springframework.web.filter.CharacterEncodingFilter"
>
> *  p:encoding="${httprequest.web.encoding:UTF-8}"*
>
> *  p:forceEncoding="${httprequest.web.encoding.force:true}" />*
>
> 
>
>
>
>
>
>
>
> http://www.springframework.org/schema/beans";
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
>xmlns:p="http://www.springframework.org/schema/p"; xmlns:aop="
> http://www.springframework.org/schema/aop";
>
>xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd";>
>
>  class="org.springframework.web.filter.CharacterEncodingFilter"
>
> *p:encoding="UTF-8"*
>
> *p:forceEncoding="true" />*
>
> 
>
>
>
> I am not sure what is  going wrong with the build after I updated the
> cas.version ?
>
>
>
>
>
> Thanks
>
>
>
> Sourabh
>
>
>
> *From:* bounce-41822094-104664...@lists.wisc.edu [mailto:
> bounce-41822094-104664...@lists.wisc.edu] *On Behalf Of *Misagh Moayyed
> *Sent:* Friday, July 10, 2015 10:18 AM
> *To:* cas-annou...@lists.ja-sig.org
> *Subject:* [cas-announce] CAS v.4.0.3 is released
>
>
>
> CAS Community,
>
>
>
> CAS version 4.0.3 [1] has been released and should shortly make its way
> into Maven central repositories, if not already. We encourage you to
> integrate this release into your own CAS maven overlay environment and
> provide feedback. Upgrading to this release from a 4.0.x version should be
> totally painless. You should find the full changelog at the linked provided
> herein.
>
>
>
> A similar announcement will shortly be posted to the Apereo.org website as
> well.
>
>
>
> Misagh
>
>
>
> [1] https://github.com/Jasig/cas/releases/tag/v4.0.3
>
>
>
> --
>
>
>
> You are currently subscribed to cas-annou...@lists.ja-sig.org as: 
> s757b...@ku.edu
>
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-announce
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: lel...@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

[cas-user] [cas-announce] CAS v.4.0.3 is released

[Batni, Sourabh]

From: Batni, Sourabh
Sent: Tuesday, August 4, 2015 2:28 PM
To: Misagh Moayyed; cas-annou...@lists.ja-sig.org
Subject: RE: [cas-announce] CAS v.4.0.3 is released

Hi Misagh

After I updated the cas.version in pom.xml to 4.0.3 from 4.0.1 the war file 
failed to deploy on tomcat and I was getting errors relating to 
characterEncodingFilter in 
filters.xml(WEB-INF/spring-configuration/filters.xml) on further looking into 
the file and comparing it with the version which was working(4.0.1) it looks 
like it is failing to load  some properties (httprequest.web.encoding:UTF-8 and 
httprequest.web.encoding.force:true) in this file. Below are the 2 versions the 
first one is the one which has the problem (4.0.3) and the second one is from 
4.0.1.

I haven't changed anything else and use the same script to build both of them,

http://www.springframework.org/schema/beans";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xmlns:p="http://www.springframework.org/schema/p"; 
xmlns:aop="http://www.springframework.org/schema/aop";
   xsi:schemaLocation="http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans.xsd";>





http://www.springframework.org/schema/beans";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xmlns:p="http://www.springframework.org/schema/p"; 
xmlns:aop="http://www.springframework.org/schema/aop";
   xsi:schemaLocation="http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans.xsd";>



I am not sure what is  going wrong with the build after I updated the 
cas.version ?


Thanks

Sourabh

From: bounce-41822094-104664...@lists.wisc.edu 
[mailto:bounce-41822094-104664...@lists.wisc.edu] On Behalf Of Misagh Moayyed
Sent: Friday, July 10, 2015 10:18 AM
To: cas-annou...@lists.ja-sig.org
Subject: [cas-announce] CAS v.4.0.3 is released

CAS Community,

CAS version 4.0.3 [1] has been released and should shortly make its way into 
Maven central repositories, if not already. We encourage you to integrate this 
release into your own CAS maven overlay environment and provide feedback. 
Upgrading to this release from a 4.0.x version should be totally painless. You 
should find the full changelog at the linked provided herein.

A similar announcement will shortly be posted to the Apereo.org website as well.

Misagh

[1] https://github.com/Jasig/cas/releases/tag/v4.0.3



--



You are currently subscribed to 
cas-annou...@lists.ja-sig.org as: 
s757b...@ku.edu

To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-announce

-- 
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] Leading White space in username/netid

[Bryan Wooten]

Thanks, I’ll test that tomorrow.

-Bryan

From: Dmitriy Kopylenko mailto:dkopyle...@unicon.net>>
Reply-To: "cas-user@lists.jasig.org" 
mailto:cas-user@lists.jasig.org>>
Date: Tuesday, August 4, 2015 at 5:23 PM
To: "cas-user@lists.jasig.org" 
mailto:cas-user@lists.jasig.org>>
Subject: Re: [cas-user] Leading White space in username/netid

https://groups.google.com/forum/m/#!topic/jasig-cas-user/pz-NZH9H7yI

Sent from my iPhone

On Aug 4, 2015, at 18:54, Bryan Wooten 
mailto:bryan.woo...@utah.edu>> wrote:

Hi all,

Here is the scenario:


  1.  Login into our CASified Peoplesoft with a leading whitespace on the user 
name.
  2.  CAS authenticates against OpenDJ just fine
  3.  Peoplesoft gets the netid/username with the leading white space in 
REMOTE_USER (We are using the Wrapper Filter)
  4.  Peoplesoft can’t resolve the principle.

Second scenario with DUO


  1.  Login into the Peoplesoft portal as a user requiring Duo MFA, again with 
leading whitespace.
  2.  Get past initial CAS login page
  3.  Duo thinks this is a new Duo user and prompts for enrollment.

What is the deal with leading whitespace? Shouldn't the LDAP bind catch this 
and not authenticate?
Should the CAS login page use javascript to trim white space?
Should the CAS server auth module trim the whitespace on the backend?

Anyway this first appeared on the duo-users mail list today and I verified the 
behavior.

Unicon CAS-MFA 3.5.2 / OpenDJ LDAP.

Thoughts?

--
You are currently subscribed to 
cas-user@lists.jasig.org as: 
dkopyle...@unicon.net
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: 
bryan.woo...@utah.edu
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] Leading White space in username/netid

[Dmitriy Kopylenko]

https://groups.google.com/forum/m/#!topic/jasig-cas-user/pz-NZH9H7yI

Sent from my iPhone

> On Aug 4, 2015, at 18:54, Bryan Wooten  wrote:
> 
> Hi all,
> 
> Here is the scenario:
> 
> Login into our CASified Peoplesoft with a leading whitespace on the user name.
> CAS authenticates against OpenDJ just fine
> Peoplesoft gets the netid/username with the leading white space in 
> REMOTE_USER (We are using the Wrapper Filter)
> Peoplesoft can’t resolve the principle.
> Second scenario with DUO
> 
> Login into the Peoplesoft portal as a user requiring Duo MFA, again with 
> leading whitespace.
> Get past initial CAS login page
> Duo thinks this is a new Duo user and prompts for enrollment.
> What is the deal with leading whitespace? Shouldn't the LDAP bind catch this 
> and not authenticate?
> Should the CAS login page use javascript to trim white space?
> Should the CAS server auth module trim the whitespace on the backend?
> 
> Anyway this first appeared on the duo-users mail list today and I verified 
> the behavior.
> 
> Unicon CAS-MFA 3.5.2 / OpenDJ LDAP.
> 
> Thoughts?
> -- 
> You are currently subscribed to cas-user@lists.jasig.org as: 
> dkopyle...@unicon.net
> 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

[cas-user] Leading White space in username/netid

[Bryan Wooten]

Hi all,

Here is the scenario:


  1.  Login into our CASified Peoplesoft with a leading whitespace on the user 
name.
  2.  CAS authenticates against OpenDJ just fine
  3.  Peoplesoft gets the netid/username with the leading white space in 
REMOTE_USER (We are using the Wrapper Filter)
  4.  Peoplesoft can’t resolve the principle.

Second scenario with DUO


  1.  Login into the Peoplesoft portal as a user requiring Duo MFA, again with 
leading whitespace.
  2.  Get past initial CAS login page
  3.  Duo thinks this is a new Duo user and prompts for enrollment.

What is the deal with leading whitespace? Shouldn't the LDAP bind catch this 
and not authenticate?
Should the CAS login page use javascript to trim white space?
Should the CAS server auth module trim the whitespace on the backend?

Anyway this first appeared on the duo-users mail list today and I verified the 
behavior.

Unicon CAS-MFA 3.5.2 / OpenDJ LDAP.

Thoughts?

-- 
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] CAS 4 (Unicon overlay) with AD plus attributes

[Misagh Moayyed]

I knew this sounded familiar, and so I dug this up:

https://github.com/Jasig/cas/issues/722



Long story short; it’s something that is fixed and will need to be 
backported to 4.0.4.



From: Misagh Moayyed [mailto:mmoay...@unicon.net]
Sent: Tuesday, August 4, 2015 11:58 AM
To: 'cas-user@lists.jasig.org' 
Subject: RE: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes



That is the default behavior, yes, supposedly :) You should not get anything 
unless you explicitly allow them.



>From what you’re describing, this sounds like a regression. Please submit an 
issue, and attach a sample of your deployerConfigFile.xml to the issue. Time 
permitting, the fix might go into 404 if it turns out to be a bug in fact.



From: Mark McCoy [mailto:mark.mc...@utsa.edu]
Sent: Tuesday, August 4, 2015 11:39 AM
To: cas-user@lists.jasig.org 
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes



I would think that the default behavior would be to restrict attributes 
unless released, instead of the reverse.



Thanks,

Mark





From: Kevin Sewell
Reply-To: "cas-user@lists.jasig.org  "
Date: Tuesday, August 4, 2015 at 12:57 PM
To: "cas-user@lists.jasig.org  "
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes



Just reporting that I'm seeing this behaviour too (but didn't play with 
filters).

I was expecting that an empty "allowedAttributes" list with 
"ignoreAttributes" set to "false" (or not specifying it) to result in no 
attribute release for that RegexRegisteredService.

The logs are telling me that my service (which is using mod_auth_cas) is 
matching that RegexRegisteredService, but it receives all the attributes no 
matter what values "allowedAttributes" and "ignoreAttributes" contain.

Can someone confirm that restricting attribute release works for them with 
v4.0.3?

If so, I'd be grateful for an example too.

Thanks,

Kevin



On 4 Aug 2015, at 17:46, Mark McCoy mailto:mark.mc...@utsa.edu> > wrote:



OK, I got the attributes released but now I have one more question.



We don’t have a need for the Services Manager, we only want to release 
attributes to one service. I added a RegexRegisteredService to the 
RegisteredServicesList and this new service has "ingnoreAttributes" set to 
"true" (releasing all attributes). I can see in the logs that when I test 
logging into this service, the SAML returned contains the attributes (we 
have to use SAML since the client isn't configurable to use the p3 
endpoint).



The problem is that attributes are always returned to *all* services no 
matter what I attempt to use to restrict them. On the default 
RegisteredService, I have set "ignoreAttributes" to "false" and 
"allowedAttributes" to an empty list. I have set a filter to be an 
impossible regex that doesn't match any attributes. I've tried releasing 
only an innocuous attribute (the uid) which the client already  gets and 
isn't a security concern. The logs even show where the uid is the only one 
that matches the filter, but the CAS server releases the other attributes 
anyway.



Are there any examples of restricting all attributes by default, and only 
allowing one service to see the attributes?







Thanks,

Mark





From: Mark McCoy
Reply-To: "cas-user@lists.jasig.org  "
Date: Friday, July 31, 2015 at 10:58 AM
To: "cas-user@lists.jasig.org  "
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes



OK, I found the solution. It was not obvious. After hunting through mailing 
list posts, I found that the instructions were on the documentation page for 
LDAP authentication all along (the section labeled "PrincipalResolver vs 
AuthenticationHandler"). Unfortunately, the instructions there to set the 
value-ref on the ldap auth handler to "#{null}" don't work. When I do that, 
I get an error:



org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean 
named 'null' is defined



I found an alternative way to do this in another mailing list post. 
Commenting out the existing 
 section, this works 
as long as there is only one handler needed:















Luckily, we don't need to use proxy auth and we have a single authentication 
handler, so we can use this. I can now see the attributes available for 
release:



2015-07-31 09:47:06,884 DEBUG 
[org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - Attribute 
map for abc123: {uid=abc123, mail=mark.mc...@utsa.edu 
 , displayName=Mark McCoy, 
employeeID=}



Next up is figuring out the release policy.



Thanks,

Mark





-- 
You are currently subscribed to cas-user@lists.jasig.org 
  as: mark.mc...@utsa.edu 

To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wik

Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes

[Mark McCoy]

I'm glad It's not just me. I was starting to go a little nuts trying everything 
I could think of.

Thanks,
Mark


From: Kevin Sewell
Reply-To: "cas-user@lists.jasig.org"
Date: Tuesday, August 4, 2015 at 12:57 PM
To: "cas-user@lists.jasig.org"
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes

Just reporting that I'm seeing this behaviour too (but didn't play with 
filters).
I was expecting that an empty "allowedAttributes" list with "ignoreAttributes" 
set to "false" (or not specifying it) to result in no attribute release for 
that RegexRegisteredService.
The logs are telling me that my service (which is using mod_auth_cas) is 
matching that RegexRegisteredService, but it receives all the attributes no 
matter what values "allowedAttributes" and "ignoreAttributes" contain.
Can someone confirm that restricting attribute release works for them with 
v4.0.3?
If so, I'd be grateful for an example too.
Thanks,
Kevin

On 4 Aug 2015, at 17:46, Mark McCoy 
mailto:mark.mc...@utsa.edu>> wrote:

OK, I got the attributes released but now I have one more question.

We don’t have a need for the Services Manager, we only want to release 
attributes to one service. I added a RegexRegisteredService to the 
RegisteredServicesList and this new service has "ingnoreAttributes" set to 
"true" (releasing all attributes). I can see in the logs that when I test 
logging into this service, the SAML returned contains the attributes (we have 
to use SAML since the client isn't configurable to use the p3 endpoint).

The problem is that attributes are always returned to *all* services no matter 
what I attempt to use to restrict them. On the default RegisteredService, I 
have set "ignoreAttributes" to "false" and "allowedAttributes" to an empty 
list. I have set a filter to be an impossible regex that doesn't match any 
attributes. I've tried releasing only an innocuous attribute (the uid) which 
the client already  gets and isn't a security concern. The logs even show where 
the uid is the only one that matches the filter, but the CAS server releases 
the other attributes anyway.

Are there any examples of restricting all attributes by default, and only 
allowing one service to see the attributes?



Thanks,
Mark


From: Mark McCoy
Reply-To: "cas-user@lists.jasig.org"
Date: Friday, July 31, 2015 at 10:58 AM
To: "cas-user@lists.jasig.org"
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes

OK, I found the solution. It was not obvious. After hunting through mailing 
list posts, I found that the instructions were on the documentation page for 
LDAP authentication all along (the section labeled "PrincipalResolver vs 
AuthenticationHandler"). Unfortunately, the instructions there to set the 
value-ref on the ldap auth handler to "#{null}" don't work. When I do that, I 
get an error:

org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 
'null' is defined

I found an alternative way to do this in another mailing list post.  Commenting 
out the existing  
section, this works as long as there is only one handler needed:







Luckily, we don't need to use proxy auth and we have a single authentication 
handler, so we can use this. I can now see the attributes available for release:

2015-07-31 09:47:06,884 DEBUG 
[org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - Attribute map 
for abc123: {uid=abc123, 
mail=mark.mc...@utsa.edu, displayName=Mark 
McCoy, employeeID=}

Next up is figuring out the release policy.

Thanks,
Mark



--
You are currently subscribed to 
cas-user@lists.jasig.org as: 
mark.mc...@utsa.edu
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: 
khsew...@glam.ac.uk
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: 
mark.mc...@utsa.edu
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] CAS 4 (Unicon overlay) with AD plus attributes

[Misagh Moayyed]

That is the default behavior, yes, supposedly :) You should not get anything 
unless you explicitly allow them.



>From what you’re describing, this sounds like a regression. Please submit an 
issue, and attach a sample of your deployerConfigFile.xml to the issue. Time 
permitting, the fix might go into 404 if it turns out to be a bug in fact.



From: Mark McCoy [mailto:mark.mc...@utsa.edu]
Sent: Tuesday, August 4, 2015 11:39 AM
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes



I would think that the default behavior would be to restrict attributes 
unless released, instead of the reverse.



Thanks,

Mark





From: Kevin Sewell
Reply-To: "cas-user@lists.jasig.org  "
Date: Tuesday, August 4, 2015 at 12:57 PM
To: "cas-user@lists.jasig.org  "
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes



Just reporting that I'm seeing this behaviour too (but didn't play with 
filters).

I was expecting that an empty "allowedAttributes" list with 
"ignoreAttributes" set to "false" (or not specifying it) to result in no 
attribute release for that RegexRegisteredService.

The logs are telling me that my service (which is using mod_auth_cas) is 
matching that RegexRegisteredService, but it receives all the attributes no 
matter what values "allowedAttributes" and "ignoreAttributes" contain.

Can someone confirm that restricting attribute release works for them with 
v4.0.3?

If so, I'd be grateful for an example too.

Thanks,

Kevin



On 4 Aug 2015, at 17:46, Mark McCoy mailto:mark.mc...@utsa.edu> > wrote:



OK, I got the attributes released but now I have one more question.



We don’t have a need for the Services Manager, we only want to release 
attributes to one service. I added a RegexRegisteredService to the 
RegisteredServicesList and this new service has "ingnoreAttributes" set to 
"true" (releasing all attributes). I can see in the logs that when I test 
logging into this service, the SAML returned contains the attributes (we 
have to use SAML since the client isn't configurable to use the p3 
endpoint).



The problem is that attributes are always returned to *all* services no 
matter what I attempt to use to restrict them. On the default 
RegisteredService, I have set "ignoreAttributes" to "false" and 
"allowedAttributes" to an empty list. I have set a filter to be an 
impossible regex that doesn't match any attributes. I've tried releasing 
only an innocuous attribute (the uid) which the client already  gets and 
isn't a security concern. The logs even show where the uid is the only one 
that matches the filter, but the CAS server releases the other attributes 
anyway.



Are there any examples of restricting all attributes by default, and only 
allowing one service to see the attributes?







Thanks,

Mark





From: Mark McCoy
Reply-To: "cas-user@lists.jasig.org  "
Date: Friday, July 31, 2015 at 10:58 AM
To: "cas-user@lists.jasig.org  "
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes



OK, I found the solution. It was not obvious. After hunting through mailing 
list posts, I found that the instructions were on the documentation page for 
LDAP authentication all along (the section labeled "PrincipalResolver vs 
AuthenticationHandler"). Unfortunately, the instructions there to set the 
value-ref on the ldap auth handler to "#{null}" don't work. When I do that, 
I get an error:



org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean 
named 'null' is defined



I found an alternative way to do this in another mailing list post. 
Commenting out the existing 
 section, this works 
as long as there is only one handler needed:















Luckily, we don't need to use proxy auth and we have a single authentication 
handler, so we can use this. I can now see the attributes available for 
release:



2015-07-31 09:47:06,884 DEBUG 
[org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - Attribute 
map for abc123: {uid=abc123, mail=mark.mc...@utsa.edu 
 , displayName=Mark McCoy, 
employeeID=}



Next up is figuring out the release policy.



Thanks,

Mark





-- 
You are currently subscribed to cas-user@lists.jasig.org 
  as: mark.mc...@utsa.edu 

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: khsew...@glam.ac.uk 

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: mark.mc...@utsa.edu 

Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes

[Mark McCoy]

I would think that the default behavior would be to restrict attributes unless 
released, instead of the reverse.

Thanks,
Mark


From: Kevin Sewell
Reply-To: "cas-user@lists.jasig.org"
Date: Tuesday, August 4, 2015 at 12:57 PM
To: "cas-user@lists.jasig.org"
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes

Just reporting that I'm seeing this behaviour too (but didn't play with 
filters).
I was expecting that an empty "allowedAttributes" list with "ignoreAttributes" 
set to "false" (or not specifying it) to result in no attribute release for 
that RegexRegisteredService.
The logs are telling me that my service (which is using mod_auth_cas) is 
matching that RegexRegisteredService, but it receives all the attributes no 
matter what values "allowedAttributes" and "ignoreAttributes" contain.
Can someone confirm that restricting attribute release works for them with 
v4.0.3?
If so, I'd be grateful for an example too.
Thanks,
Kevin

On 4 Aug 2015, at 17:46, Mark McCoy 
mailto:mark.mc...@utsa.edu>> wrote:

OK, I got the attributes released but now I have one more question.

We don’t have a need for the Services Manager, we only want to release 
attributes to one service. I added a RegexRegisteredService to the 
RegisteredServicesList and this new service has "ingnoreAttributes" set to 
"true" (releasing all attributes). I can see in the logs that when I test 
logging into this service, the SAML returned contains the attributes (we have 
to use SAML since the client isn't configurable to use the p3 endpoint).

The problem is that attributes are always returned to *all* services no matter 
what I attempt to use to restrict them. On the default RegisteredService, I 
have set "ignoreAttributes" to "false" and "allowedAttributes" to an empty 
list. I have set a filter to be an impossible regex that doesn't match any 
attributes. I've tried releasing only an innocuous attribute (the uid) which 
the client already  gets and isn't a security concern. The logs even show where 
the uid is the only one that matches the filter, but the CAS server releases 
the other attributes anyway.

Are there any examples of restricting all attributes by default, and only 
allowing one service to see the attributes?



Thanks,
Mark


From: Mark McCoy
Reply-To: "cas-user@lists.jasig.org"
Date: Friday, July 31, 2015 at 10:58 AM
To: "cas-user@lists.jasig.org"
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes

OK, I found the solution. It was not obvious. After hunting through mailing 
list posts, I found that the instructions were on the documentation page for 
LDAP authentication all along (the section labeled "PrincipalResolver vs 
AuthenticationHandler"). Unfortunately, the instructions there to set the 
value-ref on the ldap auth handler to "#{null}" don't work. When I do that, I 
get an error:

org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 
'null' is defined

I found an alternative way to do this in another mailing list post.  Commenting 
out the existing  
section, this works as long as there is only one handler needed:







Luckily, we don't need to use proxy auth and we have a single authentication 
handler, so we can use this. I can now see the attributes available for release:

2015-07-31 09:47:06,884 DEBUG 
[org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - Attribute map 
for abc123: {uid=abc123, 
mail=mark.mc...@utsa.edu, displayName=Mark 
McCoy, employeeID=}

Next up is figuring out the release policy.

Thanks,
Mark



--
You are currently subscribed to 
cas-user@lists.jasig.org as: 
mark.mc...@utsa.edu
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: 
khsew...@glam.ac.uk
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: 
mark.mc...@utsa.edu
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] CAS 4 (Unicon overlay) with AD plus attributes

[Kevin Sewell]

Just reporting that I'm seeing this behaviour too (but didn't play with 
filters).
I was expecting that an empty "allowedAttributes" list with "ignoreAttributes" 
set to "false" (or not specifying it) to result in no attribute release for 
that RegexRegisteredService.
The logs are telling me that my service (which is using mod_auth_cas) is 
matching that RegexRegisteredService, but it receives all the attributes no 
matter what values "allowedAttributes" and "ignoreAttributes" contain.
Can someone confirm that restricting attribute release works for them with 
v4.0.3?
If so, I'd be grateful for an example too.
Thanks,
Kevin

On 4 Aug 2015, at 17:46, Mark McCoy 
mailto:mark.mc...@utsa.edu>> wrote:

OK, I got the attributes released but now I have one more question.

We don’t have a need for the Services Manager, we only want to release 
attributes to one service. I added a RegexRegisteredService to the 
RegisteredServicesList and this new service has "ingnoreAttributes" set to 
"true" (releasing all attributes). I can see in the logs that when I test 
logging into this service, the SAML returned contains the attributes (we have 
to use SAML since the client isn't configurable to use the p3 endpoint).

The problem is that attributes are always returned to *all* services no matter 
what I attempt to use to restrict them. On the default RegisteredService, I 
have set "ignoreAttributes" to "false" and "allowedAttributes" to an empty 
list. I have set a filter to be an impossible regex that doesn't match any 
attributes. I've tried releasing only an innocuous attribute (the uid) which 
the client already  gets and isn't a security concern. The logs even show where 
the uid is the only one that matches the filter, but the CAS server releases 
the other attributes anyway.

Are there any examples of restricting all attributes by default, and only 
allowing one service to see the attributes?



Thanks,
Mark


From: Mark McCoy
Reply-To: "cas-user@lists.jasig.org"
Date: Friday, July 31, 2015 at 10:58 AM
To: "cas-user@lists.jasig.org"
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes

OK, I found the solution. It was not obvious. After hunting through mailing 
list posts, I found that the instructions were on the documentation page for 
LDAP authentication all along (the section labeled "PrincipalResolver vs 
AuthenticationHandler"). Unfortunately, the instructions there to set the 
value-ref on the ldap auth handler to "#{null}" don't work. When I do that, I 
get an error:

org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 
'null' is defined

I found an alternative way to do this in another mailing list post.  Commenting 
out the existing  
section, this works as long as there is only one handler needed:







Luckily, we don't need to use proxy auth and we have a single authentication 
handler, so we can use this. I can now see the attributes available for release:

2015-07-31 09:47:06,884 DEBUG 
[org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - Attribute map 
for abc123: {uid=abc123, 
mail=mark.mc...@utsa.edu, displayName=Mark 
McCoy, employeeID=}

Next up is figuring out the release policy.

Thanks,
Mark



--
You are currently subscribed to 
cas-user@lists.jasig.org as: 
mark.mc...@utsa.edu
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: 
khsew...@glam.ac.uk
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] CAS 4 (Unicon overlay) with AD plus attributes

[Mark McCoy]

OK, I got the attributes released but now I have one more question.

We don’t have a need for the Services Manager, we only want to release 
attributes to one service. I added a RegexRegisteredService to the 
RegisteredServicesList and this new service has "ingnoreAttributes" set to 
"true" (releasing all attributes). I can see in the logs that when I test 
logging into this service, the SAML returned contains the attributes (we have 
to use SAML since the client isn't configurable to use the p3 endpoint).

The problem is that attributes are always returned to *all* services no matter 
what I attempt to use to restrict them. On the default RegisteredService, I 
have set "ignoreAttributes" to "false" and "allowedAttributes" to an empty 
list. I have set a filter to be an impossible regex that doesn't match any 
attributes. I've tried releasing only an innocuous attribute (the uid) which 
the client already  gets and isn't a security concern. The logs even show where 
the uid is the only one that matches the filter, but the CAS server releases 
the other attributes anyway.

Are there any examples of restricting all attributes by default, and only 
allowing one service to see the attributes?



Thanks,
Mark


From: Mark McCoy
Reply-To: "cas-user@lists.jasig.org"
Date: Friday, July 31, 2015 at 10:58 AM
To: "cas-user@lists.jasig.org"
Subject: Re: [cas-user] CAS 4 (Unicon overlay) with AD plus attributes

OK, I found the solution. It was not obvious. After hunting through mailing 
list posts, I found that the instructions were on the documentation page for 
LDAP authentication all along (the section labeled "PrincipalResolver vs 
AuthenticationHandler"). Unfortunately, the instructions there to set the 
value-ref on the ldap auth handler to "#{null}" don't work. When I do that, I 
get an error:

org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 
'null' is defined

I found an alternative way to do this in another mailing list post.  Commenting 
out the existing  
section, this works as long as there is only one handler needed:







Luckily, we don't need to use proxy auth and we have a single authentication 
handler, so we can use this. I can now see the attributes available for release:

2015-07-31 09:47:06,884 DEBUG 
[org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - Attribute map 
for abc123: {uid=abc123, 
mail=mark.mc...@utsa.edu, displayName=Mark 
McCoy, employeeID=}

Next up is figuring out the release policy.

Thanks,
Mark



--
You are currently subscribed to 
cas-user@lists.jasig.org as: 
mark.mc...@utsa.edu
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