The login link is A/desktop which matches and the serviceProperties
definition is A/desktop/auth
On 12/18/20 4:27 PM, Ray Bon wrote:
Colin,
This looks to be an application config issue and not related to cas
[server or client].
Is the "Login" link to A/desktop, or is it something else like
Colin,
This looks to be an application config issue and not related to cas [server or
client].
Is the "Login" link to A/desktop, or is it something else like
domain/cas/login?service=A/desktop?
Ray
On Fri, 2020-12-18 at 16:03 -0500, Colin Ryan wrote:
Notice: This message was sent from outside
Paris,
The service looks to be held on the server side. So not showing in the url is
probably not an issue.
In my test, I do get redirected to the service correctly and the service ticket
is validated. I do get failed completion for what looks like a second check of
the mfa process (that
Folks,
So in the initial iteration of my project I had my spring security
application working as it should w.r.t. to the common design/functional
patterns for Spring Security and CAS.
Let's call this Application A)
My http security definition was as follows.
http
Looking at my debug logs and comparing the cases of the single MFA provider
and of the MFA selection menu I found that the service information is lost
after a successful password authentication. E.g. the POST command at the
MFA token page only contains cas/login instead of
Rakesh,
1. There are a number of options for caching,
https://apereo.github.io/cas/6.2.x/ticketing/Configuring-Ticketing-Components.html.
Your choice will depend on what you already have (software and human), and how
you configure you cas cluster. I have worked with ehcache and hazelcast.
As the title says, the default audit log entry in CAS 6.2.X for submission
of a one-time token by a user incorrectly logs the one-time token value
under the "WHO :" field when the one-time token provided by the user is
incorrect.
Example log entry :
Audit trail record BEGIN
Hi all,
according to https://tools.ietf.org/html/rfc6749#section-4.4.3 refresh
tokens SHOULD NOT be issued for client credentials grant.
With CAS we have oauth2 services which are registered for multiple grant
types. In our case client credentials, refresh token and authorization
code. But
