If they have a public metadata file you can put the URL in the metadata
configuration element instead of the static file. CAS will download and cache
the metadata file on some sort of updating schedule ( I don't remember the
specifics), but it will help ensure you have updated metadata.
On
Scratch that. I needed an updated metadata file. Now I can authenticate and get
forwarded to the sp. Then
I get an error there. I may not be registered in their system. Waiting on a
response from them.
Thanks!!! This has been very helpful!
Keith Alston
Regent University
IT Department
Hmmm, metadata expired. So I changed the expire date in the metadata. Now I'm
getting this:
RootCasException(code=UNSATISFIED_SAML_REQUEST)
at
Yes, zoom is in production. minitab in my dev environment. Both 5.3.14. pretty
much the exact same setup.
Keith Alston
Regent University
IT Department
keit...@regent.edu
757.619.3421
From: cas-user@apereo.org on behalf of Ray Bon
Sent: Monday, April 19, 2021
Keith,
The destination URLs are different, cas and casdev.
Is minitab routing to cas or casdev and is your service defined there?
Ray
On Mon, 2021-04-19 at 17:26 +, Keith Alston (Staff) wrote:
Notice: This message was sent from outside the University of Victoria email
system. Please be
You are probably going to need to take a look in the CAS logs. It seems that it
should match, but the logs should tell you exactly what it is searching for. It
will also tell you if there was an error loading the service file when it first
tried to update it.
On Mon, 2021-04-19 at 17:26 +,
I take that back. Zoom works and it does a post request.
saml-tracer show this. Zoom works, minitab doesnt.
minitab
request---
https://casdev.regent.edu/cas/idp/profile/SAML2/POST/SSO;
>
Looks like my post URL is:
https://casdev.regent.edu/cas/idp/profile/SAML2/POST/SSO
I guess the get url has redirect in it??
Keith Alston
Regent University
IT Department
keit...@regent.edu
757.619.3421
From: 'Richard Frovarp' via CAS Community
Sent: Monday,
Since I saw someone create the URL by hand the other day, I'm going to ask the
simple question: is the request hitting the HTTP-POST binding location? POST
and Redirect are two different URLs in CAS (and I'm guessing most IdPs).
I've never had to do anything different to handle the two
It seems that my CAS SAML2.0 idp is handling SAML2 services that do GET
requests just fine.
But when I have an SP that does a SAML2 POST request my idp is not reading the
parameters
and I get the "Application Not Authorized to Use CAS" message instead of the
auth page. Difference being
I have changed cas.propierties to :
cas.authn.radius.server.nasPortId=-1
cas.authn.radius.server.nasRealPort=-1
cas.authn.radius.server.protocol=EAP_MSCHAPv2
cas.authn.radius.server.retries=3
cas.authn.radius.server.nasPortType=-1
cas.authn.radius.server.nasPort=-1
Thanks for the great hint. That helps a lot.
The core question for the CAS devs stays: Where does that leak come from? I
mean, FileWatcherService and PathWatcherService seem to be straight forward.
jephte.clain schrieb am Sonntag, 18. April 2021 um 17:06:48 UTC+2:
> hello,
>
> we noticed that
Just in case, anyone else runs into this….
Only tested for our specific use case, running your own Tomcat server version
9.x instead of using the embedded.
The issue ended up being Tomcat requires a remote IP valve to handle client IPs
behind a proxy. Added the following valve to the tomcat
13 matches
Mail list logo
