another question, may be will get some answers ;)
cas is configured to use locale cookie for localization. i use locale resolver which sets request attributes and it works for the whole UI. But the password managment email builder doesn't respect the locale cookie because it uses request.getLocale()
which reads from Accept-Language
header.
here is the snippet from cas email builder
val text = EmailMessageBodyBuilder.builder()
.properties(reset)
.parameters(parameters)
.locale(Optional.ofNullable(request.getLocale()))
any suggestion on how to set request locale somewhere in locale resolver so it works here as well. otherwise i would need to fork the class and make it use request attribute instead of getLocale()
. but that would be very dirty hack
Hello ,firends.
If I only have a Provider, how do I make the delegated authentication redirect directly to it?
I want CAS to be transparent to users and not make them choose which delegated authentication to use.
I'm configure proces on CAS 6.5 to automaticaly go to Dynamic Delegation Resolver View, and then base on email go to providers
So, we're attempting to implement surrogate authentication / impersonation in CAS 6.3.7.4, using a JDBC repository. Basic impersonation works, and I see the new user id pass through to other applications. However we have SAML integrated applications that rely on the email address as the user identifier (not username), and in these situations, all of the attributes are those of the primary, not the surrogate, which results in the SAML authentication passing the primary's email address to the SP application.
I've tried configuring some of the settings related to cas.authn.surrogate.principal.attribute-resolution-enabled
and some of the associated settings, without success.
I guess my question is - is this feature just working 'as intended', and we are correctly seeing the surrogateId of the surrogateUser, with rest of the attributes from the surrogatePrincipal (email, group memberships, etc.) or am I missing a key configuration here?
Hi. We are upgrading our CAS4.x application to 6.x. Looking at the documentation, a lot has changed in Webflows. We plan to change our main login flow with the token login process to use the new method.
However, we have two custom authentication flows and I don't know how to connect to the CAS service. Looking at our 4.x configuration, we first define servlet mappings, map URLs, then update the supportedFlowIds set, and finally point Spring to the actual XML to specify these flows. These are called by the application to /token_login_flow on the CAS servlet.
Configure CAS to know when to see /token_login_flow to start custom webflow?
Make CAS actions (like granting tickets, etc.) available to this custom web process?
<bean id="loginHandlerAdapter" class="cas.tokensso.SelectiveFlowHandlerAdapter" p:flowExecutor-ref="loginFlowExecutor" p:flowUrlHandler-ref="loginFlowUrlHandler" >
<property name="supportedFlowIds">
<util:list list-class="java.util.ArrayList">
<value>login</value>
<value>token_login</value>
<!-- <value>ip_login</value>-->
</util:list>
</property>
</bean>
<webflow:flow-registry id="loginFlowRegistry" flow-builder-services="builder">
<webflow:flow-location path="/WEB-INF/login-webflow.xml" id="login" />
<webflow:flow-location path="/WEB-INF/token-login-webflow.xml" id="token_login"/>
</webflow:flow-registry>
Please, can anybody help me? Thank you!
Another issue with Surrogate/Impersonation. This time, I've run into an interesting situation with Impersonation + MFA. Using out of the box 6.6.0, I can get mfa-simple and impersonation/surrogate working separately. However, as soon as I try and turn them both on, things break.
If I have them both on, and try to log in as +username, I go through the MFA routine and it logs in as username, without giving me the option of selecting a surrogate user.
If I have them both on, and try to log in as surrogateusername+username, I start the MFA routine, but CAS throws the following error:
2022-09-21 10:43:13,779 WARN [org.apereo.cas.mfa.simple.validation.DefaultCasSimpleMultifactorAuthenticationService] - <Principal assigned to token [username] is unauthorized for token [CASMFA-#######]>
2022-09-21 10:43:13,811 ERROR [org.apereo.cas.mfa.simple.CasSimpleMultifactorAuthenticationHandler] - <Failed to authenticate code CASMFA-######
DefaultCasSimpleMultifactorAuthenticationService.java:validate:76
CasSimpleMultifactorAuthenticationHandler.java:doAuthentication:63
AbstractPreAndPostProcessingAuthenticationHandler.java:authenticate:47
>
This means that, if I want Impersonation, it seems that I need to disable MFA, and vice versa. Has anyone been able to get both of these working simultaneously with recent (6.5.x, 6.6.x) versions of CAS?
Thanks!
Hello there, I think casinit.herokuapp.com is broken because regardless of the specified cas version I get:
version=7.0.0-SNAPSHOT
# CAS server version
cas.version=7.0.0-SNAPSHOT
Inside gradle.properties
:point_up: Edit: Hello there, I think casinit.herokuapp.com is broken because regardless of the specified cas version I get:
version=7.0.0-SNAPSHOT
# CAS server version
cas.version=7.0.0-SNAPSHOT
Inside gradle.properties
doChangePassword
parameter is present? the problem is when a user is not logged in doChangePassword
triggers password change flow after successful login. but if a customer is already logged in (TGC) it doesn't show login view in order o change password but redirects directly to the service
@/all
Hello all,
The CAS project management committee has prepared a survey to request
feedback from CAS deployers:
Our intention is to help clarify specific areas in the CAS ecosystem
that need attention, understand user demographics and common use cases
and explore opportunities to support and prioritize funding of
development activities.
There is no submission due date yet though ideally, it would be best
to finalize the results before 2022 ends. I will try to send out
monthly reminders to the list here.
Please try to keep your answers realistic, concise and objective as
much as possible. As per the last surveys, responses will surely help
and guide the project's direction. Survey results will be anonymized,
aggregated and published accordingly for wider community's review on
the Apereo blog. Details to follow.
Thank you!
On behalf of the CAS project management committee,
Misagh
P.S. If you are not able to pull up the link or have questions, please
reach out to the PMC or me directly.
Hello,
I'm trying to upgrade from CAS 6.5.5 to 6.6.1 but even though the process went successfully, we can't manage to connect on any service, all tickets are considered invalid ("Ticket is not recognized")
We are using a Redis store for tickets. The configuration file is the exact same between the two versions.
Any hint to debug that please ?
I could be wrong but I think it's this commit.
RESP3 was introduced in Redis 6.
So if you're using version 5, like me, it may not function.
required-ip-addresses: ["127.0.0.1", "172.18.0.0/22", "10.0.0.0/8"]
don't work anymore. this undocumented breaking change caused deployment to fail because health endpoint cannot be accessed anymore
Dear Apereo CAS community, I am in need of some help if someone has come across a similar issue.
I'n on CAS 6.6.0 and I'm trying to implement SAML 2.0 integration by having CAS acting as a SP and delegating authentication to external IDP.
I have configured all settings to generate the SP metadata file, and I was provided with the IDP metadata file as well.
The problem is that the IDP entity wants to use the Artifact resolution service and sends us back a SAMLart (artifact). At this point, the flow returns back to CAS and it stays there.
It seems that CAS does not know what to do with the SAML artifact once it receives it from IDP, when technically it should be calling the endpoint specified by the ArtifactResolutionService from the IDP metadata file.
From tracing the SAML request/responses, I can tell that CAS is not calling anything else once it receives the SAMLart from the IDP after user authenticates successfully.
I ran a separate test by using the IDP service at https://samltest.id/ and everything is working fine, but I think the difference here is that this IDP doesn't use artifact binding, it goes a simpler way of HTTP-POST I believe.
So my question is: Does CAS SAML 2.0 integration support this artifact binding (sending artifact resolve request / receiving artifact response)?
If so, what could I be missing in my configurations?
If not, where would I need to modify CAS code to perform a SOAP request with the SAML artifact to receive the assertion?
somehow
classpath:config/appliction.yaml
is being ignored butclasspath:application.yaml
gets loaded. according to spring boot 2.7 docsconfig/application.yaml
should be loaded as before. so what did change in cas 6.6 that changed this behavior?
i tracked down this issue to some changes between 6.6.0-RC5 and 6.6.0. both versions use spring boot 2.7. so its not a boot problem. the changes in the cas code cause config files from classpath:config
not being loaded even when are specified in src/main/resources/application.yml
spring.config.additional-location=config/
can someone advice me how to force cas auth again when
doChangePassword
parameter is present? the problem is when a user is not logged indoChangePassword
triggers password change flow after successful login. but if a customer is already logged in (TGC) it doesn't show login view in order o change password but redirects directly to the service
@mmoayyed can you please advice, how to trigger password change when sso is active (valid TGC present)? I tried renew=true but it just prompts for password and after login it redirects back to the service=foo
instead of showing password change flow. so the only current way is to logout customer and redirect him to cas change his password. but if he cancels the password change action then he kind of logged out for nothing and has to log in back. not the best UX I guess. so the best would be i guess, to redirect to cas with renew=true&doChangePassword
, after successful login, perform change password operation and logout (quite common flow on many portals)
Hi, we want to use apareo cas as oidc server , but we have the problem, that attribute in the scope email, openid are returned as array not as string. we use ldap as datasource
cas.authn.attribute-repository.ldap[0].attributes.mail=email
cas.authn.attribute-repository.ldap[0].attributes.cn=name
cas.authn.attribute-repository.ldap[0].attributes.sn=family_name
cas.authn.attribute-repository.ldap[0].attributes.cn=name
cas.authn.attribute-repository.ldap[0].attributes.givenName=given_name
in the logs we see
attributes={name=[customuser2], given_name=[Elke], family_name=[Tretsuser], email=[foo2@bar.com]}, id=customuser2, scopes=[email, openid, profile], client_id=clientid}
cas version 6.6.0
org.apereo.cas.pm.web.flow.actions.PasswordChangeAction
and may be other actions are not localized which leads to such inconsistent ux. any suggestions on how to link those with messageSource
?
DefaultCommunicationsManager
uses messageSource to localize email subject and message property resolution using #{foo.bar} works but the locale is wrong. the email body is correct because of the EmailMessageBodyBuilder
uses resolved locale but communication manager never receives locale to use, thus, it uses default locale. so the email is body is in german but subject in english. public class DefaultCommunicationsManager { ....
return messageSource.getMessage(matcher.group(1), args.toArray(),
"Email Subject", ObjectUtils.defaultIfNull(emailRequest.getLocale(), Locale.getDefault()));
...
}
public class SendPasswordResetInstructionsAction { .....
val emailRequest = EmailMessageRequest.builder().emailProperties(reset)
.principal(person)
.to(List.of(to)).body(text).build();
return this.communicationsManager.email(emailRequest);
}
Looks like they updated it, just haven't made a release