As an additional debugging point, I tested this on 7.1.0-SNAPSHOT and it
loads all services as expected, so it looks like this is 7.0.x specific.
On Tuesday, June 11, 2024 at 12:49:33 PM UTC-4 Josh wrote:
> Hi Meysam -
>
> Here is the JDK version we are running in our DEV env
>
&
:08:20 AM UTC-4 Meysam Shirazi wrote:
> Hi Josh
> Check the JDK version.
>
> On Friday, April 12, 2024 at 12:41:49 AM UTC+3:30 Josh wrote:
>
>> Hi all -
>>
>> We're in the process of migrating from CAS 6.6.x to CAS 7.0.x. We have
>> several hundred service
Hi all -
Running into an odd issue here. After
https://apereo.github.io/2024/05/18/oauth-vuln/ was released, we upgrade
our nodes to 6.6.15.1. We're pushing this same logic to a new set of nodes
and are receiving the following error:
Unable to find image 'apereo/cas:6.6.15.1' locally
docker:
Hi all -
We're in the process of migrating from CAS 6.6.x to CAS 7.0.x. We have
several hundred services in our production environment working fine,
however when starting CAS 7.0.3 in our test environment it seems to bail
out hard loading some specific services and the application shuts down.
t_to = [link1: url2];
> }
> }
> }
> }
> }
> }
> return new InterruptResponse(message: message, links: redirect_to,
> block: block, ssoEnabled: sso_enabled, interrupt: interru
We're seeing the same thing on our end moving from 6.4.x to 6.6.x
2023-02-16 18:52:47,362 DEBUG
[org.apereo.cas.interrupt.webflow.actions.InquireInterruptAction] -
2023-02-16 18:52:47,362 DEBUG
[org.apereo.cas.interrupt.BaseInterruptInquirer] -
2023-02-16 18:52:47,362 DEBUG
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
Were you able to find a solution to this? We're running into this on our
sub-production instance of CAS but have not experienced it on any
production instances yet.
On Saturday, December 21, 2019 at 12:34:13 AM UTC-5, windhamg wrote:
>
> Hi all,
>
> I'm testing CAS 6.1.2 in an external Jetty
Apologies, I see you have that already, I mis-read the original post :)
On Thursday, January 23, 2020 at 10:32:36 AM UTC-5, Josh wrote:
>
> You dont need an allowedAttributes sections for this, just an
> attributeReleasePolicy like so:
>
>attributeReleasePolicy : {
&
You dont need an allowedAttributes sections for this, just an
attributeReleasePolicy like so:
attributeReleasePolicy : {
@class : org.apereo.cas.services.ReturnMappedAttributeReleasePolicy
allowedAttributes : {
@class : java.util.TreeMap
mail :
, January 22, 2020 at 9:45:40 AM UTC-5, Christine Pasek wrote:
>
> Hello Josh,
>
> I have just upgraded from 5.2.X to 5.3.X and am experiencing the same
> error and like you, everything seems to be working fine.
>
> Were you able to find a solution to fixing this error
Hi all -
We have recently upgraded from CAS 5.2.x to CAS 6.1.x - everything appears
to be working as expected, however we are seeing the below very frequently
in our error logs (dozens of times per minute). We saw these errors while
testing/validating but it was not nearly as frequent.
>
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
s:tc:SAML:1.1:nameid-format:emailAddress
https://---BASE-URL---/SAMLRedirector/ClientSAMLLogin.aspx"/>
On Monday, August 19, 2019 at 11:07:01 PM UTC, Josh wrote:
>
> Were you able to find a solution to this? We're running into the same
> issue with Concur Solutions
Were you able to find a solution to this? We're running into the same issue
with Concur Solutions on CAS v5.2.4.
On Thursday, April 18, 2019 at 3:40:02 PM UTC, JC wrote:
>
> We are trying to setup CAS 5.2.6 for use with Concur Solutions as the SP.
> Per their tech support, they only support IdP
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:*
24 matches
Mail list logo
