Thanks Andy.
Normal CAS authentications are working fine with the service definition that I
have and the service redirects are working as you indicated.
I don’t think there are any service redirects (or any services that need to be
defined) for the spring security method. At least if I
Micas,
Check out what Dave Curry wrote at:
https://dacurry-tns.github.io/deploying-apereo-cas/building_server_ldap_resolution-release_overview.html
It gives one method on how to do what you want.
From: cas-user@apereo.org [mailto:cas-user@apereo.org] On Behalf Of Micas Camela
Yes. Or you could create an attribute release policy in your service
definition
(https://apereo.github.io/cas/5.1.x/integration/Attribute-Release-Policies.html).
If what you are doing though meets your needs I would stick with it since it
is simpler.
From: cas-user@apereo.org
You probably want something like this in your cas.properties:
cas.authn.ldap[0].principalAttributeList=sAMAccountName,givenName,sn,mail,memberOf,distinguishedName
Of course put in the attributes that you want to release.
From: cas-user@apereo.org [mailto:cas-user@apereo.org] On
If you are wanting to put in your own credentials the format is:
cas.authn.accept.users=casuser::Mellon,username::password
You, of course, can just remove the first item in the list since you probably
don’t want the default and then add commas in between username/password pairs.
Doug
Christian,
I believe I ran into this too at one point. If I remember correctly you just
need to add the following dependency to your CAS overlay pom.xml file:
org.apereo.cas
cas-server-support-json-service-registry
${cas.version}
Ah. Yes. Sorry about that. I just had a note on that when I was playing
around with it and didn’t notice that I had set that in the
application.properties. Glad you figured it out.
From: cas-user@apereo.org [mailto:cas-user@apereo.org] On Behalf Of Sandor
Juhasz
Sent: Tuesday,
Yeah. So in my cas I had to change this to match my Nginx proxy so I am
guessing in your case if you change these to your load balancer that will help
things a little bit.
Doug
From: cas-user@apereo.org [mailto:cas-user@apereo.org] On Behalf Of casuser
Sent: Thursday, December 14, 2017
This may not be what you are working for or it might be different in 5.2.0 or
it is possible I am forgetting something else but I believe all I did is the
following:
Configure CAS to only listen on port 8080
Edit cas.properties and add the following lines:
# configure CAS to only
I’m curious what you have for your cas.server.name and cas.server.prefix
properties. They are the https address of your load balancer, right?
Another thing I realize that might be different is that I am not currently
using a load balance but just using Nginx to proxy all web requests
Check out: https://github.com/kcbanner/node-cas
There are usage examples on the page.
From: cas-user@apereo.org [mailto:cas-user@apereo.org] On Behalf Of shah ilyas
Sent: Friday, October 26, 2018 8:00 AM
To: CAS Community
Subject: [cas-user] Node JS CAS client
is there any CAS client
Fahmi,
My guess is that you have not put the skelton_in_ID.properties file in the
correct location. I believe it should be in the src/main/resources folder.
Also, the setting you have for cas.messageBundle.baseNames doesn’t look right
to me.
The default setting is:
Sorry I am not sure what to tell you. I assume your cas.properties file is
located at /etc/cas/config/cas.properties. Also, you could try increasing the
logging to see if anything interesting shows up in the logs. I don’t know how
to list the currently registered services or even if it is
Pedro,
I think you want to use
cas.serviceRegistry.json.location=file:/etc/cas/services
instead of
cas.serviceRegistry.config.location: file:/etc/cas/services
I am just looking at my configuration and that is what I have and I seem to
remember this property name changing
Thanks Jeff! That was exactly the information I needed and helps me to
understand how things work better. Much appreciated.
Doug
From: cas-user@apereo.org [mailto:cas-user@apereo.org] On Behalf Of Jeff Sittler
Sent: Friday, September 14, 2018 5:13 PM
To: CAS Community
Subject:
You might check out the server configuration section of the CAS deployment
guide that David Curry has put together
https://dacurry-tns.github.io/deploying-apereo-cas/building_server_configure-server-properties.html.
My guess is that there is a slight mistake in what you are currently doing
...@email.arizona.edu <mailto:windh...@email.arizona.edu>
Office: +1 520 626 5981
On Sun, Apr 28, 2019 at 8:26 PM Doug Campbell mailto:wdouglascampb...@gmail.com> > wrote:
I don’t know if this is an ideal workaround but I found in my case if I changed
the transcoder setting from KY
directory). It will get built and placed in the war.
https://apereo.github.io/cas/5.3.x/installation/Maven-Overlay-Installation.html
Ray
On Wed, 2019-05-01 at 17:09 +0800, Doug Campbell wrote:
Thanks Julien.
I think I understand what is needed to be done for registering the missing
Correction. I think I had things cached. It doesn’t work to put the files in
src/main/resources.
From: cas-user@apereo.org [mailto:cas-user@apereo.org] On Behalf Of Doug
Campbell
Sent: Friday, May 3, 2019 12:06 AM
To: cas-user@apereo.org
Subject: RE: [cas-user] Issue with LPPE
On Fri, 2019-05-03 at 00:20 +0800, Doug Campbell wrote:
Correction. I think I had things cached. It doesn’t work to put the files in
src/main/resources.
From: cas-user@apereo.org <mailto:cas-user@apereo.org>
[mailto:cas-user@apereo.org] On Behalf Of Doug Campbell
Sent: Friday, May 3
@apereo.org] On Behalf Of Ray Bon
Sent: Friday, May 3, 2019 2:14 AM
To: cas-user@apereo.org
Subject: Re: [cas-user] Issue with LPPE and memcached ticket registry
val is part of lombok. Try adding this to build.gradle
compileOnly group: 'org.projectlombok', name: 'lombok', version: '
my overlay, probably for the errors you are seeing. But I do not
see a reference to projectlombok in cas master branch (or 6.0.x).
Some IDEs have lombok plugins but that should not be necessary for command line
build.
Perhaps there is someone with more experience with lombok on the list.
Gary,
I don’t have an answer but I saw this same error yesterday when I was testing
proxy authentication on my CAS 6.0.3 test setup. In my case I haven’t
configured LPPE. I did try disabling it just now but that seemed to have no
effect as the error still occurs. In my case I am using
Daniel,
Have you taken a lot at the phpCAS examples at
https://github.com/apereo/phpCAS/tree/master/docs/examples? They are really
detailed with a lot of comments explaining what is happening and even
mentioning what things should be for testing and what should be removed when
deploying
Daniel,
I would recommend “getting your feet wet” first by working with the
example_simple.php script. Make sure to get this one working with your CAS
server first and then build from there by working with the example_service.php
which could act like your CAS protected API service and
Perhaps your web server doesn’t have write permissions to the location your
debug.log is being written. Usually it is a good idea to create a subdirectory
that gives such rights to the web server and then tell the script to put the
debug.log there. I think a simple work around for the time
Did you first get the example_simple.php script working? If not, do that
first. If you have I have often found that looking in the debug.log informs me
as to what is going wrong and would suggest you look there. Also, I don’t
think you mentioned which version of the CAS server you are
Are you testing this on an internal server that isn’t accessible to the CAS
server?
The following is in your debug log:
The supplied proxy callback url MY_CLIENT_URL could not be
authenticated. Either MY_CLIENT_URL cannot be reached, it is not
allowed to exercise proxy authentication
This is probably the same issue as the debug.log files. The web server must
have the ability to read/write the location where the proxy granting tickets
are stored. There is probably some indication of this in the debug.log.
OR
Did you configure the CAS server to allow this service to
ovarp' via CAS Community [mailto:cas-user@apereo.org]
Sent: Wednesday, September 23, 2020 9:54 AM
To: cas-user@apereo.org
Subject: Re: [cas-user] Configure SAML2 IdP functionality to provide SSO for G
Suite
The cert you were using under the old integration likely doesn't match your
SAML cert. You wou
A warning to others on what I wrote as instructions. I accidently left in
validUntil="2020-09-25T20:17:03Z" in the sp-metadata.xml file. You would want
to remove this or otherwise things won’t work.
From: cas-user@apereo.org [mailto:cas-user@apereo.org] On Behalf Of Doug
Cam
Responding a little to my own question. I don’t have it fully figured out yet
but I did find a significant issue. I had left my service file for the old
Google Apps SAML integration method in my services directory and I think this
was intercepting things. I’m not getting the same error as
32 matches
Mail list logo
