mmoayyed on master
clean up bean names for saml2 m… allow ticket registry to query … allow ticket registry to query … and 2 more (compare)
mmoayyed on 6.6.x
Update SamlIdPMetadataConfigura… (compare)
mmoayyed on master
troubleshoot hanging builds - w… troubleshoot hanging builds - w… troubleshoot hanging builds - w… and 3 more (compare)
mmoayyed on master
minor refactoring to allow for … doc updates doc updates and 1 more (compare)
Looks like they updated it, just haven't made a release
def run(Object[] args) {
def ALLOWED_EMAIL_DOMAIN="whatever.com"
def attributes = args[0];
def id = args[1];
def service = args[2];
def logger = args[3];
def suffix = "@" + ALLOWED_EMAIL_DOMAIN.toLowerCase()
if (id.toLowerCase().endsWith(suffix)) {
return id.substring(0, id.length() - suffix.length())
}
return id
}
Hello All, I am trying to build cas management app and when I enable AWS service registry like dynamodb or S3, I get the following error, for dynamodb it creates the table and then fails to start:
APPLICATION FAILED TO START
Description:
Parameter 1 of method restAuthenticationService in org.apereo.cas.rest.config.CasCoreRestConfiguration$CasCoreRestAuthenticationConfiguration required a bean of type 'org.apereo.cas.authentication.MultifactorAuthenticationTriggerSelectionStrategy' that could not be found.
The injection point has the following annotations:
- @org.springframework.beans.factory.annotation.Qualifier(value="defaultMultifactorTriggerSelectionStrategy")
Action:
Consider defining a bean of type 'org.apereo.cas.authentication.MultifactorAuthenticationTriggerSelectionStrategy' in your configuration.
Anyone have any ideas why this would be happening? if I remove the cas management AWS dependency it works fine.
Hi Guys! I was perplexed by SLO for a long time.
I read the doc,I understand when CAS logout, the CAS server will callback the CAS Client's URL to remind the Clinet to destroy the session.And the Client should definition an API to destroy the local session.
I followed that , but the Client never received the callback.
I want to know,if the CAS server will callback the Client?
I want to know,if the CAS server will callback the Client?
It should. Check the nginx/apache log, you should see something like:
172.20.0.83 - - [16/Nov/2022:02:37:02 +0100] "POST /EsupUserApps/login?target=https%3A%2F%2Fent.univ-paris1.fr%2Faccueil%2F HTTP/1.1" 200 0 "-" "Apache-HttpClient/4.5.6 (Java/11.0.16)"
hi,
Probably a neophyte question but I can't find the simple way to define an attribute from a header field with "trusted" authentication.
CAS authentication is simply done through an apache reverse proxy which defines an "APP_REMOTE_USER" header that I easily retrieve via:
cas.authn.trusted.remote-principal-header=app_remote_user
The proxy also provisions a 'GRP_FROM_APP' business header which I can clearly see in the debug log :
2022-11-17 10:02:56,702 DEBUG [org.apereo.cas.adaptors.trusted.web.flow.PrincipalFromRequestHeaderNonInteractiveCredentialsAction] - <Available request headers are [{referer=[https://XXXX], x-forwarded-port=[443], app_remote_user=[T01722], host=[XXX], connection=[Keep-Alive], cache-control=max-age=0],
....
grp_from_app=[017,223], cookie=[JSESSIONID=9Pt2j2GDjZTpmG09pVb525jCRRgVtTznCW8kgWDvJM8H2GJfGSMn!...
Chrome/107.0.0.0 Safari/537.36], sec-fetch-dest=[document]}]. Locating first header value for [app_remote_user]>
2022-11-17 10:02:56,705 DEBUG [org.apereo.cas.adaptors.trusted.web.flow.PrincipalFromRequestHeaderNonInteractiveCredentialsAction] - <Remote user [T01722] found in [app_remote_user] header>
2022-11-17 10:02:56,706 DEBUG [org.apereo.cas.adaptors.trusted.web.flow.BasePrincipalFromNonInteractiveCredentialsAction] - <User [T01722] found in request>
2022-11-17 10:02:56,708 DEBUG [org.apereo.cas.adaptors.trusted.web.flow.BasePrincipalFromNonInteractiveCredentialsAction] - <Attributes [{}] found in request>
But there, I can't recover this header to transform it into an attribute. It looks like "Trusted" authentication doesn't provision any attributes other than the principal.
What method would allow me to add this attribute to cas clients?
Thanks
Hello,
I upgraded to the latest version (7.0.0-snapshot) and now I easily and directly retrieve ALL the attributes present in the Trusted header.
I admit that I didn't easily understand how to use attribute-header-patterns in cas.properties.
In my case, I used:
cas.authn.trusted.attribute-header-patterns=(APP_REMOTE_USER|GRP_FROM_APP)->(.+)
Not very intuitive but is it correct ?
Regards
Hi all,
Could someone please assist with the below issue I am facing? Thank you.
Here is my environment (note that the frontend and backend are served from different domains):
Tech stack:
org.jasig.cas.client:cas-client-core v3.4.1
spring boot 1.5.4
Java 1.8
Here is what is happening:
(1) user accesses the frontend, but there is no session cookie yet, so the user is redirected to CAS login page served by the CAS Server.
(2) user enters correct login, and the CAS login page redirects to the ticket validating endpoint (login/cas?ticket=XXX....) served by the backend.
(3) the backend responds with a session cookie and redirects to the frontend URL.
The problem is that the cookie in step 2 is only valid for the backend domain, and not the frontend domain so all the requests from the frontend fail because the cookie isn't sent to the backend in requests. Anyone know a way around this? Can the cookie somehow be made cross-domain? Perhaps via configuration on the CAS Server? Please excuse my lack of knowledge w.r.t. the CAS protocol. Thank you
80
to the URL - something like https://<domain>:80/cas/clientredirect?client_name=AzureAD&service=https://<clientapp domain>/login instead of https://<domain>/cas/clientredirect?client_name=AzureAD&service=https://<clientapp domain>/login. This causes the redirect URL to break on the browser side. If we remove the 80 port manually from the URL within the browser, then things work fine. Is there a way to stop this port being added to the URL? I tried to configure the auto-redirect-type parameter for this service to be "SERVICE" thinking that it would make CAS invisible to the client but that didn't make any difference either