Hello!
I have an working CAS 5.3 and i'm trying to use OIDC, but my user profiles
are not respecting my configuration.
While debugging the application during the OIDC profile attribute release
and filtering process, i've found a potential issue and would like to check
if its a bug or intentional feature.
The problem is: after the user authenticate and consent with the release
policy, CAS starts building the user profile for release. During this
process, class OAuthRegisteredService buildService, method is called, and
it creates a service this way (without using service request header):
if (StringUtils.isBlank(id)) {
id = registeredService.getClientId();
}
return webApplicationServiceServiceFactory.createService(id);
So the new service is created using the "clientId".
Lets suppose that the service is registered like the documentation example
below, the the service will be created with the identifier '*client*':
{
"@class" : "org.apereo.cas.services.OidcRegisteredService",
"clientId": "client",
"clientSecret": "secret",
"serviceId" : "^<https://the-redirect-uri>",
"name": "OIDC",
"id": 1000}
Ok, now, during the profile building process (eg: when i call /oidc/profile
API) the class DefaultOAuth20UserProfileDataCreator will be called:
protected Principal getAccessTokenAuthenticationPrincipal(final
AccessToken accessToken, final J2EContext context) {
*final Service service = accessToken.getService(); final
RegisteredService registeredService =
this.servicesManager.findServiceBy(service);*
...
}
The profile data creator tries to find the service by using
servicesManager.findServiceby(Object). This object is the service that was
constructed using the 'clientId' param from the registry. The
DefaultServicesManager/AbstractServicesManager implements this method by
delegating the call to another method:
public RegisteredService findServiceBy(final Service service) {
return service != null ? findServiceBy(service.getId()) : null;
}
public RegisteredService findServiceBy(final String serviceId) {
if (StringUtils.isBlank(serviceId)) {
return null;
}
final RegisteredService service =
getCandidateServicesToMatch(serviceId)
.stream()
.filter(r -> r.matches(serviceId))
.findFirst()
.orElse(null);
if (service != null) {
service.initialize();
}
final RegisteredService result = validateRegisteredService(service);
return result;
}
This will result in the DefaultServicesManager trying to locate the service
using the clientId as a param, but is matches this param against the
service URI regex validation.
Is this the intended behavior? I must use the URI in the registry clientId
param? If this is the intended behavior, then the documentation should be
changed.
If its not the intended behavior, can we get a fix for version 5.3? I'm
tempted to just overrride the findServiceBy(...) method in a custom
services manager, but i'm not sure if its a bug or a intended behavior.
Thanks for your time,
Lucas Francisco Delgado Duarte.
--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAMTDOVq3-C9YQeEdTC_XcwRXZicDBx2KedJfE91HefSVJJM81w%40mail.gmail.com.
