The service is defined as a cluster using hazelcast, but I had shut down the
other node prior to conducting these tests. Hazelcast still seems to decode
tickets and whatnot in this degenerate cluster, but there's only a single node
available.
On Wed, Sep 05, 2018 at 03:53:29PM -0700, Travis Sch
Any ideas?
I also want to pass username to password change url when it triggers force
to change password.
On Thursday, May 17, 2018 at 9:08:15 AM UTC-7, Mr Rao wrote:
>
> Hi,
> Any one has ideas on this?
>
> Rao
>
>
> On Wednesday, May 16, 2018 at 10:12:13 PM UTC-7, Mr Rao wrote:
>>
>> Hi,
>>
Hi Baron,
> ... shared session mechanism ...
I agree with Travis, without shared session some function (e.g. OAuth,
pac4j...) of CAS might not work properly.
To verified that shared session might or might not be a problem, *try
minimize your cluster to only a single node*, if that worked, then
We had a similar issue with a service that was behind a load balancer. I
Benito@Unicon helped to identify the issue. The IP address of the client is
used in the generation of the session ID. Once our service went to producion
the volume of requests was great and the pool of IDs was limited by th
If you are running in case servers in a cluster I think it is required to
use some shared session mechanism between the nodes for the current OAuth
implementation. This is due to the pac4j reliance on server side session
store. This might cause your issue.
On Wed, Sep 5, 2018, 1:23 PM Baron Fuji
Here are the debug logs for the client's attempt. I've just redacted some of
the potentially sensitive local info and hazelcast related entries.
2018-09-05 09:11:23,754 DEBUG
[org.apereo.cas.support.oauth.DefaultOAuthCasClientRedirectActionBuilder] -
http://cas.example.edu/cas/login?service=htt
Happy to provide more debug logs. Since the logs at DEBUG level are so verbose
I tried to excerpt what I thought would be relevant. Any suggestions on
anything in particular?
Unfortunately, while we have medium to longer term plans to upgrade to 5.3,
upgrading from 5.0 is not an option in the s
Hi,
We are running CAS 3.6 with tomcat 8 and in some instances when 2 users are
logging in user A is logged in as User B on the client application. So the
session information for the first user ends up being used.
We noticed that in the tomcat access logs both users shared the same
Jsessioni
For what it's worth, we've been running with the locally-patched version of
the Duo Web SDK since June 11th and have not had any issues with it at all.
--Dave
--
DAVID A. CURRY, CISSP
*DIRECTOR OF INFORMATION SECURITY*
INFORMATION TECHNOLOGY
71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003
+1 212 22
That all makes sense to me. I doesn't really help with selling the
technology stack and, generally speaking MFA to our constituents. A little
angst isn't all bad; It's just a little bad.
Thanks for the prompt reply and for originally uncovering this.
On Wednesday, September 5, 2018 at 10:24:
I did not submit our patch to the CAS code base because, frankly, it's not
a CAS bug.
It's a bug (or at least poor design) in the Duo Web SDK that interacts
negatively with a poor design decision made by Microsoft in the
implementation of Internet Explorer and, for reasons known only to them,
pres
Hi all,
I'm wondering if this was ever submitted to the CAS code base.
I'm running CAS 5.2.7 and we are using DUO for MFA. Last week, migrated a
vendor from Shibboleth to CAS for IDP services and the issue described here
began to happen. The authn request is signed and in IE the total length
Hi Baron,
Maybe some more debug logs will helps with debugging this issue?
*/cas/oauth2.0/callbackAuthorize* is an intermediate URL, usually no need
to know about it. So that why the doc didn't specified it.
Maybe you can try upgrading it to CAS 5.3 and see if the problem still
exists. CAS OAu
13 matches
Mail list logo
