Error "403 Forbidden" on "CAS management => Administration => Release Attributes" (CAS server 665 + CAS management 662)
Luís Costa
I've recently installed "CAS server 665 and "CAS management 662".
I've configured all of CAS server actuators to be available with ANONYMOUS access (for initial testing purposes).
I think I've included all the needed dependencies in both "CAS server and "CAS managment.
I'm using JSON service registry for testing purposes, and I have one service configured, which is correctly recognized by CAS management.
CAS management is apparently working well on almoust all options i've tested, as an example, I can change my service JSON file configs with CAS management.
I've also been able to successefully test "CAS management => Administration => RESOLVE Attributes".
I'm having the following error when testing option "CAS management => Administration => RELEASE Attributes" with the above configured service:
CAS management log:
2023-04-19 18:46:52,618 [https-jsse-nio-8445-exec-2] ERROR: 403 :
"<Map><timestamp>2023-04-19T17:46:52.365+00:00</timestamp><status>403</status><error>Forbidden</error><trace>org.apereo.cas.services.UnauthorizedSsoServiceException:
service.not.authorized.sso<EOL>?
at org.apereo.cas.authentication.handler.RegisteredServiceAuthenticationHandlerResolver.supports(RegisteredServiceAuthenticationHandlerResolver.java:122)<EOL>?
at org.apereo.cas.authentication.DefaultAuthenticationEventExecutionPlan.lambda$getAuthenticationHandlers$4(DefaultAuthenticationEventExecutionPlan.java:161)<EOL>?
(...)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)<EOL>?at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)<EOL>?
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)<EOL>?at java.base/java.lang.Thread.run(Thread.java:833)<EOL></trace><path>/sso/actuator/releaseAttributes</path></Map>"
at org.springframework.web.client.HttpClientErrorException.create(HttpClientErrorException.java:109)
at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:168)
(...)
2023-04-19 18:46:52,654 [https-jsse-nio-8445-exec-2] ERROR: Servlet.service() for servlet [dispatcherServlet] in context with path [/cas-management] threw exception
java.lang.RuntimeException: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.NullPointerException: Cannot invoke "org.apereo.cas.mgmt.domain.Attributes.getAttributes()" because the return value of "org.apereo.cas.mgmt.DashboardController.callCasServer(String, Object, org.springframework.core.ParameterizedTypeReference)" is null
at org.pac4j.core.engine.AbstractExceptionAwareLogic.runtimeException(AbstractExceptionAwareLogic.java:64)
at org.pac4j.core.engine.AbstractExceptionAwareLogic.handleException(AbstractExceptionAwareLogic.java:49)
at org.pac4j.core.engine.DefaultSecurityLogic.perform(DefaultSecurityLogic.java:163)
(...)
Caused by: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.NullPointerException: Cannot invoke "org.apereo.cas.mgmt.domain.Attributes.getAttributes()" because the return value of "org.apereo.cas.mgmt.DashboardController.callCasServer(String, Object, org.springframework.core.ParameterizedTypeReference)" is null
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1014)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:517)
Caused by: java.lang.NullPointerException: Cannot invoke "org.apereo.cas.mgmt.domain.Attributes.getAttributes()" because the return value of "org.apereo.cas.mgmt.DashboardController.callCasServer(String, Object, org.springframework.core.ParameterizedTypeReference)" is null
at org.apereo.cas.mgmt.DashboardController.release(DashboardController.java:170)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
(...)
CAS server log:
2023-04-20 18:04:53,974 [https-jsse-nio-8443-exec-3] WARN : Service [AbstractWebApplicationService(id=casdemo665, originalUrl=casdemo665, artifactId=null, principal=null, source=service, loggedOutAlready=false, format=XML, attributes={service=[casdemo665], username=[ABExyz]})] is not allowed to use SSO.
2023-04-20 18:04:53,975 [https-jsse-nio-8443-exec-3] INFO : Audit trail record BEGIN
=============================================================
WHO: ABE001731
WHAT: [UsernamePasswordCredential(username=ABE001731, source=null, customFields={})]
ACTION: AUTHENTICATION_FAILED
APPLICATION: CAS
WHEN: Thu Apr 20 18:04:53 WEST 2023
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1
=============================================================
If I try to call the actuator like this (don't know if it's the right way),
https://localhost:8443/cas/actuator/releaseAttributes?username=ABExyz&password=somepassword&service=casdemo665
I get the following information on CAS server log:
2023-04-21 15:11:09,619 [https-jsse-nio-8443-exec-2] ERROR: Service unauthorized
RegisteredServiceAccessStrategyAuditableEnforcer.java:lambda$execute$6:200
Optional.java:orElseGet:364
RegisteredServiceAccessStrategyAuditableEnforcer.java:execute:194
I've tried to use "CAS server 665 and "CAS management 661", which I think, looking at "CAS management 661" dependencies, makes more sense,
but with this configuration, CAS management gets worse, for example, I can't manage by service JSON file base configs (get a blank screen),
so I've got back to "CAS server 665 and "CAS management 662", on which my only problem so far is with "CAS management => Administration => RESOLVE Attributes".
My questions:
-Am I missing some configuration on properties files of CAS server and/or CAS management?
-Am I missing some configuration on JSON file of my casdemo665 service?
-Is there a known issue with "CAS server 665 + CAS management 6.6.2" on "CAS management => Administration => RESOLVE Attributes"?
Can anybody help me with this issue, please?
Ray Bon
Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.
Ray Bon
Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.
Hello Ray,
Thank you for you answer, I'm sorry for the delay in replying.
>> >> Luis
>> >> if I try to call the actuator like this (don't know if it's the right way),
>> >>
>> >>
>> >> I get the following information on CAS server log:
>> >>
>> >> 2023-04-21 15:11:09,619 [https-jsse-nio-8443-exec-2] ERROR: Service unauthorized
>> >> RegisteredServiceAccessStrategyAuditableEnforcer.java:lambda$execute$6:200
>> >> Optional.java:orElseGet:364
>> >> RegisteredServiceAccessStrategyAuditableEnforcer.java:execute:194
>> Ray
>> Put cas management aside while you work with the actuators for cas.
I referenced the use of CAS server actuators because it seems to me that some of CAS management functionalities call CAS server actuators under the hood.
I base this opinion on this information:
>> https://groups.google.com/a/apereo.org/g/cas-user/c/crOUxHaXh_k/m/ZTPDH5kwAAAJ
>>
>> The "dashboard" and "CAS Info" tabs of the https://my-domain/cas-management/dashboard
>> are now populated with data coming from my CAS server /health and /info actuators.
I think, don’t know for sure, that as some CAS management information comes from CAS server actuators, like /health and /info, so does the attribute release information must come from the same source, CAS server actuators.
If my analysis with Chrome DevTools is correct, the following happens when calling, for example:
CAS management => Administration => Resolve Attributes
GET https://localhost:8445/cas-management/api/dashboard/resolve/<username>
This option works fine. I think that under the hood it calls this CAS server actuator,https://apereo.github.io/cas/6.6.x/integration/Attribute-Resolution.html#actuator-endpoints
CAS management => Administration => Release Attributes
POST https://localhost:8445/cas-management/api/dashboard/release
This option causes the “403” mentioned error.
POST does exist as an actuator endpoint, as stated here,
https://apereo.github.io/cas/6.6.x/integration/Attribute-Release-Policies.html#actuator-endpoints
but I’m not sure if this functionality should make a POST (POST inside cas management, it’s true, I could not find out what kind of request is made from CAS management to CAS server), I think I should make a GET, does this makes sense?
Is it possible that CAS management should make a GET instead of a POST on this functionality and this is a bug?
>> Ray
>> You can edit the json service definition by hand if needed.
I've been doing that, editting my json files, but right now my goal is to test CAS management, because, as the documentation below states, when I use other backend (not JSON Service Registry), which I plan to do, I will need do use CAS management, so I’m testing all it’s options.
>> CAS Management Web Application / Installing-ServicesMgmt-Webapp.md
>> ...
>> Synchronized Configuration
>> ...
>> Note that for certain type of service registry backends,
>> deploying the management web application is a requirement
>> since it acts as the interface fronting CRUD operations
>> that deal with the storage backend.
>> The absence of the management web application
>> means that you will need to find alternative tooling
>> to manually interact with your registry of choice
>> and the storage backend it employs.
>> Ray
>> You say there is a problem with cas management release attributes
>> but the url provided suggests you are accessing cas.
As I said above, based on info I’ve read on CAS google group, I think, not sure if I’m right, that cas management release attributes info is obtained from CAS server by calling an actuator, probably one of these:
https://apereo.github.io/cas/6.6.x/integration/Attribute-Release-Policies.html#actuator-endpoints
>> Ray
>> This is my local endpoint config:
##### --- management endpoints
# cas.monitor.endpoints.ldap.ldap-authz.role-attribute = description
management.endpoints.enabled-by-default=true
Luis: I also have this setting on cas.properties
management.endpoint.metrics.enabled=true
management.endpoint.env.enabled=true
management.endpoint.configurationMetadata.enabled=true
# # curl -X POST -k https://local.uvic.ca/cas/actuator/refresh was accepted but browser refresh -> 500
# # management.endpoint.refresh.enabled=true
# # not sure how to call
# # management.endpoint.autoconfig.enabled=true
# default:
# health,info
# cas built in (or part of already configured features), enabled with '*' (some may not work):
# samlValidate,yubikeyAccountRepository,loggingConfig,beans,caches,conditions,configprops,env,loggers,heapdump,threaddump,metrics,scheduledtasks,mappings,refresh,features
# cas-server-support-reports, status is auto enabled, provides:
# status,springWebflow,auditLog,registeredServices.exportRegisteredServices,ssoSession,statistics,releaseAttributes
# cas-server-core-configuration-metadata-repository configurationMetadata is auto enabled, provides:
# configurationMetadata
# cas-server-support-discovery-profile provides:
# discoveryProfile
management.endpoints.web.exposure.include=*
Luis: I also have this setting on cas.properties
# https://apereo.github.io/2018/11/06/cas6-admin-endpoints-security/
# must specify auto enabled / default endpoints if using exposure.include
# management.endpoints.web.exposure.include=health,info,configurationMetadata,discoveryProfile,auditLog
# # cas.monitor.endpoints.endpoint.defaults.access[0]=IP_ADDRESS
# # cas.monitor.endpoints.endpoint.defaults.requiredIpAddresses[0]=\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}
# # #cas.monitor.endpoints.endpoint.defaults.requiredIpAddresses[0]=127\\.0\\.0\\.1
# # shows free memory
# management.endpoint.health.show-details=always
# # shows health items below
# management.health.defaults.enabled=true
# # on by default
# # management.health.memoryHealthIndicator.enabled=true
# # management.health.systemHealthIndicator.enabled=true
# # management.health.sessionHealthIndicator.enabled=true
# # management.health.hazelcastHealthIndicator.enabled=true
# # management.health.pooledLdapConnectionFactoryHealthIndicator.enabled=true
# # management.health.samlRegisteredServiceMetadataHealthIndicator.enabled=true
management.endpoint.ticketExpirationPolicies.enabled=true
Luis: I don’t have this config, think I don’t need it for my CAS management tests
management.endpoints.web.exposure.include=*
Luis: I also have this setting on cas.properties, it’s duplicated on this config
# # can not be accessed once authenticated. I know, weird, right?
cas.monitor.endpoints.endpoint.health.access=ANONYMOUS
# # cas.monitor.endpoints.endpoint.info.access=ANONYMOUS
# spring.security.user.name=casuser
spring.security.user.password=Some secret, spaces are cool
# cas.monitor.endpoints.endpoint.defaults.access=AUTHENTICATED
cas.monitor.endpoints.endpoint.defaults.access=ANONYMOUS
Luis: for now I have all actuator access ANONYMOUS, for testing purposes
Luis: cas.monitor.endpoints.endpoint.defaults.access=ANONYMOUS
Luis:What makes me think that my "CAS management => Administration => Release Attributes" “403” problem might be a bug is:
-all other CAS management features that I’ve tested work fine (eg Manage Services, Resolve Attributes)
-couldn’t find anybody on this group stating that it can use this feature correctly on cas management 6.6.2
Does my above reasoning make sense?
Luís Costa
Hello Ray,
Thank you for you answer, I'm sorry for the delay in replying.
>> >> Luis
>> >> if I try to call the actuator like this (don't know if it's the right way),
>> >>
>> >>
>> >> I get the following information on CAS server log:
>> >>
>> >> 2023-04-21 15:11:09,619 [https-jsse-nio-8443-exec-2] ERROR: Service unauthorized
>> >> RegisteredServiceAccessStrategyAuditableEnforcer.java:lambda$execute$6:200
>> >> Optional.java:orElseGet:364
>> >> RegisteredServiceAccessStrategyAuditableEnforcer.java:execute:194
>> Ray
>> Put cas management aside while you work with the actuators for cas.
I referenced the use of CAS server actuators because it seems to me that some of CAS management functionalities call CAS server actuators under the hood.
I base this opinion on this information:
>> https://groups.google.com/a/apereo.org/g/cas-user/c/crOUxHaXh_k/m/ZTPDH5kwAAAJ
>>
>> The "dashboard" and "CAS Info" tabs of the https://my-domain/cas-management/dashboard
>> are now populated with data coming from my CAS server /health and /info actuators.
I think, don’t know for sure, that as some CAS management information comes from CAS server actuators, like /health and /info, so does the attribute release information must come from the same source, CAS server actuators.
If my analysis with Chrome DevTools is correct, the following happens when calling, for example:
CAS management => Administration => Resolve Attributes
GET https://localhost:8445/cas-management/api/dashboard/resolve/<username>
This option works fine. I think that under the hood it calls this CAS server actuator, https://apereo.github.io/cas/6.6.x/integration/Attribute-Resolution.html#actuator-endpoints
CAS management => Administration => Release Attributes
POST https://localhost:8445/cas-management/api/dashboard/release
This option causes the “403” mentioned error.
POST does exist as an actuator endpoint, as stated here,
https://apereo.github.io/cas/6.6.x/integration/Attribute-Release-Policies.html#actuator-endpoints
but I’m not sure if this functionality should make a POST (POST inside cas management, it’s true, I could not find out what kind of request is made from CAS management to CAS server), I think I should make a GET, does this makes sense?
Is it possible that CAS management should make a GET instead of a POST on this functionality and this is a bug?
>> Ray
>> You can edit the json service definition by hand if needed.
I've been doing that, editting my json files, but right now my goal is to test CAS management, because, as the documentation below states, when I use other backend (not JSON Service Registry), which I plan to do, I will need do use CAS management, so I’m testing all it’s options.
>> CAS Management Web Application / Installing-ServicesMgmt-Webapp.md
>> ...
>> Synchronized Configuration
>> ...
>> Note that for certain type of service registry backends,
>> deploying the management web application is a requirement
>> since it acts as the interface fronting CRUD operations
>> that deal with the storage backend.
>> The absence of the management web application
>> means that you will need to find alternative tooling
>> to manually interact with your registry of choice
>> and the storage backend it employs.
>> Ray
>> You say there is a problem with cas management release attributes
>> but the url provided suggests you are accessing cas.
As I said above, based on info I’ve read on CAS google group, I think, not sure if I’m right, that cas management release attributes info is obtained from CAS server by calling an actuator, probably one of these:
https://apereo.github.io/cas/6.6.x/integration/Attribute-Release-Policies.html#actuator-endpoints
>> Ray
>> This is my local endpoint config:
##### --- management endpoints
# cas.monitor.endpoints.ldap.ldap-authz.role-attribute = description
management.endpoints.enabled-by-default=true
Luis: I also have this setting on cas.properties
management.endpoint.metrics.enabled=true
management.endpoint.env.enabled=true
management.endpoint.configurationMetadata.enabled=true
# # curl -X POST -k https://local.uvic.ca/cas/actuator/refresh was accepted but browser refresh -> 500
# # management.endpoint.refresh.enabled=true
# # not sure how to call
# # management.endpoint.autoconfig.enabled=true
# default:
# health,info
# cas built in (or part of already configured features), enabled with '*' (some may not work):
# samlValidate,yubikeyAccountRepository,loggingConfig,beans,caches,conditions,configprops,env,loggers,heapdump,threaddump,metrics,scheduledtasks,mappings,refresh,features
# cas-server-support-reports, status is auto enabled, provides:
# status,springWebflow,auditLog,registeredServices.exportRegisteredServices,ssoSession,statistics,releaseAttributes
# cas-server-core-configuration-metadata-repository configurationMetadata is auto enabled, provides:
# configurationMetadata
# cas-server-support-discovery-profile provides:
# discoveryProfile
management.endpoints.web.exposure.include=*
Luis: I also have this setting on cas.properties
# https://apereo.github.io/2018/11/06/cas6-admin-endpoints-security/
# must specify auto enabled / default endpoints if using exposure.include
# management.endpoints.web.exposure.include=health,info,configurationMetadata,discoveryProfile,auditLog
# # cas.monitor.endpoints.endpoint.defaults.access[0]=IP_ADDRESS
# # cas.monitor.endpoints.endpoint.defaults.requiredIpAddresses[0]=\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}
# # #cas.monitor.endpoints.endpoint.defaults.requiredIpAddresses[0]=127\\.0\\.0\\.1
# # shows free memory
# management.endpoint.health.show-details=always
# # shows health items below
# management.health.defaults.enabled=true
# # on by default
# # management.health.memoryHealthIndicator.enabled=true
# # management.health.systemHealthIndicator.enabled=true
# # management.health.sessionHealthIndicator.enabled=true
# # management.health.hazelcastHealthIndicator.enabled=true
# # management.health.pooledLdapConnectionFactoryHealthIndicator.enabled=true
# # management.health.samlRegisteredServiceMetadataHealthIndicator.enabled=true
management.endpoint.ticketExpirationPolicies.enabled=true
Luis: I don’t have this config, think I don’t need it for my CAS management tests
management.endpoints.web.exposure.include=*
Luis: I also have this setting on cas.properties, it’s duplicated on this config
# # can not be accessed once authenticated. I know, weird, right?
cas.monitor.endpoints.endpoint.health.access=ANONYMOUS
# # cas.monitor.endpoints.endpoint.info.access=ANONYMOUS
# spring.security.user.name=casuser
spring.security.user.password=Some secret, spaces are cool
# cas.monitor.endpoints.endpoint.defaults.access=AUTHENTICATED
cas.monitor.endpoints.endpoint.defaults.access=ANONYMOUS
Luis: for now I have all actuator access ANONYMOUS, for testing purposes
Luis: cas.monitor.endpoints.endpoint.defaults.access=ANONYMOUS
Luis:
What makes me think that my "CAS management => Administration => Release Attributes" “403” problem might be a bug is:
-all other CAS management features that I’ve tested work fine (eg Manage Services, Resolve Attributes)
-couldn’t find anybody on this group stating that it can use this feature correctly on cas management 6.6.2
Does my above reasoning make sense?
Luís Costa
>>
>> I, too, expect that cas management will get some of its config from cas.
Sorry for the delay in answering.
I’ve confirmed that CAS management uses CAS server actuators for “Attribue Release” feature, by:
-adding cas-mgmt-support-dashboard dependency to CAS management
-analyzing/ debugging class “org.apereo.cas.mgmt.DashboardController”, method “release”, which does a “return this.<Attributes>callCasServer("/actuator/releaseAttributes", data, new ParameterizedTypeReference<Attributes>() {}).getAttributes();
I think the [callCasServer("/actuator/releaseAttributes”] code confirms that CAS management uses a CAS server actuator for this feature.
>> I have not yet tested that and have attributes listed in both properties files.
When you say “have attributes listed in both properties files”, you mean you have attribute release related configs on both cas.properties and management.properties, similar to the following?
# cas.properties
cas.authn.attribute-repository.core.default-attributes-to-release=cn:username
# management.properties (based on https://groups.google.com/a/apereo.org/g/cas-user/c/E26U_rI-LN0/m/2Q73b3KVAAAJ)
cas.authn.attributeRepository.stub.attributes.cn:cn
>> I am not sure whether a POST or GET should be used.
The code for invoking Resolve Attributes and Release Attributes on the “org.apereo.cas.mgmt.DashboardController” class looks very similar.
resolve method, ok
return this.<Attributes>callCasServer("/actuator/resolveAttributes/" + id,new ParameterizedTypeReference<Attributes>() {}).getAttributes();
release method, error 403
return this.<Attributes>callCasServer("/actuator/releaseAttributes", data,new ParameterizedTypeReference<Attributes>() {}).getAttributes();
I’ve debugged the code and noticed that the release method indeed does a POST
val resp = restTemplate.exchange(prefix + endpoint, HttpMethod.POST, req, type);
And the resolve method does a GET
val resp = restTemplate.exchange(prefix + endpoint, HttpMethod.GET, null, type);
It’s true that Release Attributes has both GET and POST endpoints (https://apereo.github.io/cas/6.6.x/integration/Attribute-Release-Policies.html#actuator-endpoints), so the POST is valid, but I’m not sure if in the “CAS management => Administration => Release Attributes” should do a POST, a GET makes more sense to me.
>> One thing to consider is your certificates for https.
>> If you are using self signed certs, you may have to add them
>> to the JVM certs list (not just tomcat, or whatever server app you are using).
>> I believe the JVM will block requests for unknown certs.
I noticed that I’ve previously come across that problem, which manifest as the following error:
ERROR [org.jasig.cas.client.util.CommonUtils] - SSL error getting response from host: localhost : Error Message: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I think that it occurs because the CAS client included in the CAS management application, when trying to reach the CAS server, can’t trust the CAS server Tomcat certificate.
I’ve solved that problem by, as you mentioned, adding the CAS server certificate to the OS JDK 17.
Because some CAS management application features work well (eg “CAS management => Administration => Resolve Attributes”) and this one not (“CAS management => Administration => Release Attributes”), I think my current issue is not certificate related.
>> Ray
Thank’s for the help Ray.
For the moment I’ll keep thinking this might be a bug on cas-management-662.
Maybe I’ll try to see org.apereo.cas.mgmt.DashboardController Git history or think about other options I have on this issue.
Regards
Luís Costa
Hello Ray,
Regarding this subject, I finally found what my problem was.
I was passing a wrong value in "CAS management => Administration => Release Attributes => Service"
I was passing:
Username: <myUser>
Password: <mypassword>
Service: <myServiceNAME>, eg “myServiceName”
when the correct values should be
Username: <myUser>
Password: <mypassword>
Service: <myServiceURL>, eg https://.*myServiceName.*
The code below throw an UnauthorizedSsoServiceException, because registeredService was getting null, due to not matching my wrong “Service” value “myServiceName”.
org.apereo.cas.authentication.handler.RegisteredServiceAuthenticationHandlerResolver
@Override
public boolean supports(final Set<AuthenticationHandler> handlers, final AuthenticationTransaction transaction) {
val service = authenticationServiceSelectionPlan.resolveService(transaction.getService());
if (service != null) {
==> val registeredService = this.servicesManager.findServiceBy(service);
LOGGER.trace("Located registered service definition [{}] for this authentication transaction", registeredService);
if ( ==> registeredService == null <== || !registeredService.getAccessStrategy().isServiceAccessAllowed()) {
LOGGER.warn("Service [{}] is not allowed to use SSO.", service);
throw new UnauthorizedSsoServiceException();
}
CAS management called the https://localhost:8443/sso/actuator/releaseAttributes CAS server actuator in this feature/screen, with POST and the three parameters above, just as explained in the docs (https://apereo.github.io/cas/6.6.x/integration/Attribute-Release-Policies.html#actuator-endpoints).
I was able to reproduce the error with curl (instead of manually testing with cas management):
curl -v -k -d '{"username":"myUser","password":"mypassword","service":"https://.*myServiceName.*"}' -H 'Content-Type: application/json' https://localhost:8443/sso/actuator/releaseAttributes.
What caused my mistake, was that “Service=myServiceName” works fine on "CAS management => Administration => RESOLVE Attributes", but it makes sense that the value passed on “Service” matches the serviceId on the JSON service registy file for my service.
In conclusion, no bug on "CAS management => Administration => Release Attributes", just my error when passing value of “Service” parameter.