[cas-user] Re: 6.1.1 JSON error with REST authn after update

[Andy Ng]

Hi all,

Still don't know how to fix it, but I found something here:

In CAS 5.3.14, see here: 
https://github.com/apereo/cas/blob/v5.3.14/core/cas-server-core-authentication-api/src/main/java/org/apereo/cas/authentication/principal/SimplePrincipal.java#L50

SimplePrincipal attribute is:
private Map attributes = new HashMap<>();

But in CAS 6.1.1, see here 
https://github.com/apereo/cas/blob/v6.1.1/core/cas-server-core-authentication-api/src/main/java/org/apereo/cas/authentication/principal/SimplePrincipal.java#L53

SimplePrincipal attribute is:
private Map> attributes = new HashMap<>();


Maybe this is related to the bug we encountered here?

- Andy



-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/ca431760-3cfe-4ad7-bf50-4bedebe62b7a%40apereo.org.

Re: [cas-user] Mongodb Authentication won't work if no attributes given in CAS 6.1.1

[Andy Ng]

Hi Jérôme,

Yes that will be the best.

Cheers!
- Andy

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/55f404bb-38fe-435f-be32-53c362832fa0%40apereo.org.

Re: [cas-user] Compiling Mod-auth-cas with external OpenSSL

[Colin Ryan]

David,

You tweaked my brain. It was indeed a libcurl thing. While I had the 
right versions it obviously was using system OpenSSL so for those stuck 
in the future for what it's worth


* Rebuilt my OpenSSL with shared support.
* Was then able to build my own version of libcurl with

./configure --prefix=/opt/aa --with-ssl=/opt/aa --enable-libcurl

-option


* Then was able to rebuild mod_auth_cas - but I still needed to have 
LD_FLAGS="-ldl"


./configure --prefix=/opt/aa --with-apxs=/opt/aa/bin/apxs 
--with-apr=/opt/aa/bin/apr-1-config --with-openssl=/opt/aa 
--with-libcurl=/opt/aa


So far so good.

Thanks All.

C

On 2019-11-04 1:05 p.m., David Hawes wrote:

On Mon, 4 Nov 2019 at 12:01, Colin Ryan  wrote:

David,

Yes I've built Apache2 itself with SSL using the safe external OpenSSL as I"m 
trying to use with the module. When I run the totally to stock ./configure line I 
posted it gives me

checking for openssl/ssl.h in /opt/aa... yes

checking whether compiling and linking against OpenSSL works... no

checking for CRYPTO_new_ex_data in -lcrypto... yes

checking openssl/crypto.h usability... yes

checking openssl/crypto.h presence... yes

checking for openssl/crypto.h... yes

checking openssl/x509.h usability... yes

checking openssl/x509.h presence... yes

checking for openssl/x509.h... yes


Everything compiles but when I install and ldd the .so of the module it's 
linked to the system's OpenSSL lib's not the ones in my /opt/aa patch.

This is likely showing libraries linked to libcurl. Can you change the
output by setting LD_LIBRARY_PATH=/opt/aa/lib before running ldd?


If I export export CPPFLAGS="-I/opt/aa/include" and LDFLAGS="-L/opt/aa/lib/ 
-ldl"

Then I get "yes" on the compiling and linking line but the ldd still indicates 
linkage to the system's version. I suspect the -ldl is needed as I'm dealing with the 
static OpenSSL  libssl.a and libcrypto.a..

If you're using a recent OpenSSL (1.1), you likely aren't linking
against libssl and libcrypto at all. Removing or commenting out lines
13529-13743 of configure (master) will remove these checks.



--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/956ddcd6-2d10-b028-0870-745bcca596a5%40caveo.ca.

Re: [cas-user] Compiling Mod-auth-cas with external OpenSSL

[David Hawes]

On Mon, 4 Nov 2019 at 12:01, Colin Ryan  wrote:
>
> David,
>
> Yes I've built Apache2 itself with SSL using the safe external OpenSSL as I"m 
> trying to use with the module. When I run the totally to stock ./configure 
> line I posted it gives me
>
> checking for openssl/ssl.h in /opt/aa... yes
>
> checking whether compiling and linking against OpenSSL works... no
>
> checking for CRYPTO_new_ex_data in -lcrypto... yes
>
> checking openssl/crypto.h usability... yes
>
> checking openssl/crypto.h presence... yes
>
> checking for openssl/crypto.h... yes
>
> checking openssl/x509.h usability... yes
>
> checking openssl/x509.h presence... yes
>
> checking for openssl/x509.h... yes
>
>
> Everything compiles but when I install and ldd the .so of the module it's 
> linked to the system's OpenSSL lib's not the ones in my /opt/aa patch.

This is likely showing libraries linked to libcurl. Can you change the
output by setting LD_LIBRARY_PATH=/opt/aa/lib before running ldd?

> If I export export CPPFLAGS="-I/opt/aa/include" and LDFLAGS="-L/opt/aa/lib/ 
> -ldl"
>
> Then I get "yes" on the compiling and linking line but the ldd still 
> indicates linkage to the system's version. I suspect the -ldl is needed as 
> I'm dealing with the static OpenSSL  libssl.a and libcrypto.a..

If you're using a recent OpenSSL (1.1), you likely aren't linking
against libssl and libcrypto at all. Removing or commenting out lines
13529-13743 of configure (master) will remove these checks.

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAAgu-wDUoUrmhiJFjdi_JmdD6brkQ8KDEtrn3qMwRZFoEW%2B06A%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [cas-user] mod_auth_cas and attributes

[Ray Bon]

Alberto,

My apologies. I missed the part about cas protocol v2. Attribute release is 
available only with protocol v3 and saml 1.1 (and saml 2).

Ray

On Mon, 2019-11-04 at 13:17 +0100, Alberto Cabello Sánchez wrote:

On Fri, 25 Oct 2019 18:08:13 +

Ray Bon <



r...@uvic.ca

> wrote:


Alberto,


To be sure CAS is releasing the attributes:







Thanks, Ray.


It seems to be right:


DEBUG [org.apereo.cas.services.AbstractRegisteredServiceAttributeReleasePolicy]

mailto:albe...@unex.es>

albe...@unex.es

], sn=[cabello sánchez], sn1=[cabello], sn2=[sánchez],

uid=[alberto]}]>


I wonder how the "serviceValidate" endpoint is building the service response.


Could this be useful? The log shows attributes being used for access control


WHO: audit:unknown

WHAT: [result=Service Access Granted,service=



https://server.unex.es/examples/jsp/he...,principal=SimplePrincipal(id=alberto

, attributes={cn=[alberto], givenName=[alberto], 
irisPersonalUniqueID=[DOC:12345678R], mail=[



albe...@unex.es

], sn=[cabello sánchez], sn1=[cabello], sn2=[sánchez], 
uid=[alberto]}),requiredAttributes={}]

ACTION: SERVICE_ACCESS_ENFORCEMENT_TRIGGERED

APPLICATION: CAS


but not for service ticket validation


WHO: alberto

WHAT: ST-16c60***d099 for



https://server.unex.es/examples/jsp/headers.jsp


ACTION: SERVICE_TICKET_VALIDATED

APPLICATION: CAS


Additionally: I can use attributes to control access in .htaccess (with

Require cas-attribute givenName:alberto) but -as expected- it works for me

only in the SAML scenario, not in the CASv2.


--

Alberto Cabello Sánchez

Servicio de Informática

Universidad de Extremadura


--

Ray Bon
Programmer Analyst
Development Services, University Systems
2507218831 | CLE 019 | r...@uvic.ca

I respectfully acknowledge that my place of work is located within the 
ancestral, traditional and unceded territory of the Songhees, Esquimalt and 
WSÁNEĆ Nations.

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/2e8fac5c9572d6e77afdd446193a23691e07ccc2.camel%40uvic.ca.

Re: [cas-user] Compiling Mod-auth-cas with external OpenSSL

[Colin Ryan]

David,

Yes I've built Apache2 itself with SSL using the safe external OpenSSL 
as I"m trying to use with the module. When I run the totally to stock 
./configure line I posted it gives me


checking for openssl/ssl.h in /opt/aa... yes

checking whether compiling and linking against OpenSSL works... no

checking for CRYPTO_new_ex_data in -lcrypto... yes

checking openssl/crypto.h usability... yes

checking openssl/crypto.h presence... yes

checking for openssl/crypto.h... yes

checking openssl/x509.h usability... yes

checking openssl/x509.h presence... yes

checking for openssl/x509.h... yes


Everything compiles but when I install and ldd the .so of the module 
it's linked to the system's OpenSSL lib's not the ones in my /opt/aa patch.


If I export export CPPFLAGS="-I/opt/aa/include" and 
LDFLAGS="-L/opt/aa/lib/ -ldl"


Then I get "yes" on the compiling and linking line but the ldd still 
indicates linkage to the system's version. I suspect the -ldl is needed 
as I'm dealing with the static OpenSSL  libssl.a and libcrypto.a..


But results still show what they show. As I've mentioned I've had to do 
this in the past with other components and the right incarnation of 
environment variables always seems to work it's magic. Just wondering if 
I'm missing something obvious in this case.


Thanks

Colin



On 2019-11-02 12:44 p.m., David Hawes wrote:

On Fri, 1 Nov 2019 at 15:41, Colin Ryan  wrote:

Folks,

For various reason's I need to compile my own mod_auth_cas module for
use in Apache. I also have my own builds of OpenSSL  within this toolchain.


I cannot for the life of me seem to get mod_auth_cas to use my external
openssl libraries. I've done this many times before for other software
components. I've tried all the tricks of setting OPENSSL_LIBS, CPPFLAGS,
-ldl flag PKG_CONFIG_DIR etc etc that have worked in the past to no
avail. No matter what I do it says it can find ssl.h, finds -lssl, finds
-lcrypto BUT complains that it cannot find an link to OpenSSL and then
builds with the systems default libraries as revealed by an "ldd" on the
resulting mod_auth_so.c

What exact error do you get?

You should just need --with-openssl, but I've built with CPPFLAGS and
LDFLAGS as well.

I'd recommend using the same version of OpenSSL for Apache, curl, and
mod_auth_cas unless you want headaches.



--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/81f31e26-f3d7-15aa-7e90-0a2f5efb611d%40caveo.ca.

[cas-user] Re: 6.1.1 JSON error with REST authn after update

[Chris M.]

Hello!

We have the same problem as Alex here. 

Thanks!


Le jeudi 31 octobre 2019 13:52:52 UTC-4, Alex.B. a écrit :
>
> Hi,
>
> We updated CAS from 5.3.14 to 6.1.1 and the REST authn doesn't work 
> anymore. Nothing changed on the rest service side (the same JSON is 
> returned to CAS).
>
> *We get this error :*
>
> 2019-10-31 11:27:34,293 ERROR 
> [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - <[
> service_name]: [Error while extracting response for type [class 
> org.apereo.cas.authentication.principal.SimplePrincipal] and content type 
> [application/json;charset=UTF-8]; nested exception is 
> org.springframework.http.converter.HttpMessageNotReadableException: JSON 
> parse error: Cannot deserialize instance of 
> `java.util.ArrayList` out of VALUE_STRING token; nested 
> exception is com.fasterxml.jackson.databind.exc.MismatchedInputException: 
> Cannot deserialize instance of `java.util.ArrayList` out 
> of VALUE_STRING token
>  at [Source: (PushbackInputStream); line: 1, column: 104] (through 
> reference chain: 
> org.apereo.cas.authentication.principal.SimplePrincipal["attributes"]->java.util.LinkedHashMap["mail"])
>  
> / JSON parse error: Cannot deserialize instance of 
> `java.util.ArrayList` out of VALUE_STRING token; nested 
> exception is com.fasterxml.jackson.databind.exc.MismatchedInputException: 
> Cannot deserialize instance of `java.util.ArrayList` out 
> of VALUE_STRING token
>  at [Source: (PushbackInputStream); line: 1, column: 104] (through 
> reference chain: 
> org.apereo.cas.authentication.principal.SimplePrincipal["attributes"]->java.util.LinkedHashMap["mail"])]>
>
>
> *cas.properties :*
>
> cas.authn.rest.uri=https://service_uri
> cas.authn.rest.name=service_name
>
> *This is an example of the JSON we are receiving from the REST service :*
>
> { "@class": "org.apereo.cas.authentication.principal.SimplePrincipal", 
> "id": "TEST01", "attributes": { "eduPersonAffiliation": ["employee", 
> "member"], "bciCodeEtablissement": "123456", "bciMatricule": "NULL_VALUE", 
> "mail": "test...@test.com ", "sn": "Test", "givenName": 
> "Test", "displayName": "test Test", "isMemberOf": ["na...@test.com 
> ", "registr...@test.com ", "
> abc-scien...@test.com ", "klm-etude...@test.com ", 
> "klm-etude...@test.com ", "klm-prap...@test.com ", 
> "klm.sans...@test.com "] } }
>
> Thank you for your help!
>
> Alex.
>

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/afa2f256-a60d-4034-8c00-01a3e6e7d08d%40apereo.org.

Re: [cas-user] Mongodb Authentication won't work if no attributes given in CAS 6.1.1

[Jérôme LELEU]

Hi,

I saw his answer. I understand the concern and the need for consistency in
CAS, but the same is worth for pac4j as well: I could change the default
behavior in pac4j, but this would impact users just to accommodate with the
consistency of CAS.

My feeling is that the default behavior of pac4j should be kept, but
changed when used in CAS to have consistency in both systems (alone or
bundle).

Here is my proposal: by default, in CAS, the id,username,password
attributes are defined, which makes things consistent in CAS: no need to
define the attributes, consistent in pac4j and things will work properly.
What do you think?

Thanks.
Best regards,
Jérôme




Le lun. 4 nov. 2019 à 09:51, Andy Ng  a écrit :

> Hi Jérôme,
>
> PR was declined because Moayyed considered this behavior as something need
> to be fixed in pac4j, see this:
>
> Since defining attributes is necessary for pac4j to work when using
> MongoDB Authentication, the attributes properties is necessary here.
> However, this behavior of requiring attributes is different from other
> authentication methods (e.g.JDBC), so I proposed to add an warning here for
> clarity sake. See if agree.
>
> Thanks for the patch but none of this sounds right.
>
> Attribute support is always optional. All authentication methods in CAS
> work with or without presence of attributes in the authentication source. A
> design choice or limitation of a library should not have to contract
> consistent behavior elsewhere. Changes need to be done on pac4j to allow
> attribute-less authentication.
>
>
> Should I bring this discussion to pac4j group instead? Thanks.
>
> Cheers!
> - Andy
>
> --
> - Website: https://apereo.github.io/cas
> - Gitter Chatroom: https://gitter.im/apereo/cas
> - List Guidelines: https://goo.gl/1VRrw7
> - Contributions: https://goo.gl/mh7qDG
> ---
> You received this message because you are subscribed to the Google Groups
> "CAS Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-user+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/84c1396e-647e-484c-b2db-1325250b621f%40apereo.org
> 
> .
>

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAP279LyUrT6YWAhEaw83dOo9je%3DdUNDZhVttwjHyDKe541s6rQ%40mail.gmail.com.

Re: [cas-user] mod_auth_cas and attributes

[Alberto Cabello Sánchez]

On Fri, 25 Oct 2019 18:08:13 +
Ray Bon  wrote:

> Alberto,
> 
> To be sure CAS is releasing the attributes:
> 
> 
>  name="org.apereo.cas.services.AbstractRegisteredServiceAttributeReleasePolicy"
>  level="debug"/>

Thanks, Ray.

It seems to be right:

DEBUG [org.apereo.cas.services.AbstractRegisteredServiceAttributeReleasePolicy]


I wonder how the "serviceValidate" endpoint is building the service response.

Could this be useful? The log shows attributes being used for access control

WHO: audit:unknown
WHAT: [result=Service Access 
Granted,service=https://server.unex.es/examples/jsp/he...,principal=SimplePrincipal(id=alberto,
 attributes={cn=[alberto], givenName=[alberto], 
irisPersonalUniqueID=[DOC:12345678R], mail=[albe...@unex.es], sn=[cabello 
sánchez], sn1=[cabello], sn2=[sánchez], uid=[alberto]}),requiredAttributes={}]
ACTION: SERVICE_ACCESS_ENFORCEMENT_TRIGGERED
APPLICATION: CAS

but not for service ticket validation

WHO: alberto
WHAT: ST-16c60***d099 for 
https://server.unex.es/examples/jsp/headers.jsp
ACTION: SERVICE_TICKET_VALIDATED
APPLICATION: CAS

Additionally: I can use attributes to control access in .htaccess (with
Require cas-attribute givenName:alberto) but -as expected- it works for me
only in the SAML scenario, not in the CASv2. 

-- 
Alberto Cabello Sánchez
Servicio de Informática
Universidad de Extremadura

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/20191104131745.e9bf1d095e4c607b1214cc32%40unex.es.

Re: [cas-user] Mongodb Authentication won't work if no attributes given in CAS 6.1.1

[Andy Ng]

Hi Jérôme,

PR was declined because Moayyed considered this behavior as something need 
to be fixed in pac4j, see this:

Since defining attributes is necessary for pac4j to work when using MongoDB 
Authentication, the attributes properties is necessary here. However, this 
behavior of requiring attributes is different from other authentication 
methods (e.g.JDBC), so I proposed to add an warning here for clarity sake. 
See if agree.

Thanks for the patch but none of this sounds right.

Attribute support is always optional. All authentication methods in CAS 
work with or without presence of attributes in the authentication source. A 
design choice or limitation of a library should not have to contract 
consistent behavior elsewhere. Changes need to be done on pac4j to allow 
attribute-less authentication.


Should I bring this discussion to pac4j group instead? Thanks.

Cheers!
- Andy

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/84c1396e-647e-484c-b2db-1325250b621f%40apereo.org.