Bumping this. Has anyone had any luck configuring this or a suitable work
around that keeps CAS within the auth flow?
On Monday, June 28, 2021 at 12:22:07 PM UTC-4 Josh G wrote:
> We are currently running CAS 6.3 as a CAS and SAML IdP, both of which use
> LDAP for authentication. We have
We are currently running CAS 6.3 as a CAS and SAML IdP, both of which use
LDAP for authentication. We have Azure AD (as a service) configured to
authenticate through CAS using SAML which has been working perfectly fine
for years.
Our Desktop Management team is looking to expand our usage of
We recently attempted to upgrade our CAS environment from v6.1.X to v6.2.X.
While things looked stable in our TEST environment, we are experiencing an
unexpected, but replicable, issue in our PROD environment.
Two services that we are aware of (PingOne and WebEx) are triggering CAS to
return a
our 6.1.0 upgrade?
On Monday, September 9, 2019 at 6:45:11 AM UTC, Misagh Moayyed wrote:
>
> Can you try this with 5.3.12?
>
> On Thursday, September 5, 2019 at 6:46:44 PM UTC+4:30, Josh G wrote:
>>
>> Apologies for the bump - just wanted to see if anyone else has
Hi all -
We are working on integrating a service (dmp.cdlib.org) in our CAS 5.2.x
environment, but are having trouble accommodating a specific requirement,
specifically setting the Destination in the SAML response.
In order to validate our configuration, the vendor offers a test Shibboleth
SP
We were able to get this working by forcing the ACS binding provided by
Concur Solutions to SAML2.0 instead of SAML1.1 as provided in the vendor
supplied documentation
Example:
https://---BASE-URL---;
xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
Apache Tomcat Version: Apache Tomcat/9.0.20
----
On Friday, July 26, 2019 at 2:25:33 PM UTC, Josh G wrote:
>
> Attribute Mappings to SAML Identifiers (e.g. urn:oid:2.5.4.42) is broken
> in CAS 6.0.
>
> In CAS 5.2 (and earlier rel
Attribute Mappings to SAML Identifiers (e.g. urn:oid:2.5.4.42) is broken in
CAS 6.0.
In CAS 5.2 (and earlier releases of CAS 5.x) it was possible to map an
attribute to a SAML compatible URI by leveraging the attributeReleasePolicy
within a service definition.
*A working (CAS 5.2) example is
Support for Google Apps is broken in 5.2.9.
I assume the change that broke Google Apps on 5.3.x [1] [2] was back-fed
sometime after 5.2.4 (our current production release, which is working as
expected) and 5.2.9 (which no longer works as expected):
Related:
*
oolean that can be flipped to disable this.
>
> On Sunday, September 2, 2018 at 9:29:23 PM UTC-4, Josh G wrote:
>>
>> Its worth mentioning this issue is related to the following from July:
>>
>>
>> https://groups.google.com/a/apereo.org/forum/#!searchin/cas-use
/zrQf5Ex-CAAJ
I'd like to reiterate that patching the client is not a fix here, the core
of 5.3 needs to be patched to gracefully accept a null RequestID as all
previous versions of CAS have.
On Monday, August 27, 2018 at 3:25:32 PM UTC-4, Josh G wrote:
>
>
> CAS 5.3.x introduces a breaki
CAS 5.3.x introduces a breaking change to how RequestIDs are handled when
validating SAML Services.
*In 5.2.x (and all previous version of CAS), if the RequestID is not
present, it will gracefully fail by returning a null value:*
12 matches
Mail list logo
