Just a correction. The buildService is in the class OAuth20CasAuthenticationBuilder, not on the OAuthRegisteredService class.
Em seg, 16 de set de 2019 às 17:41, Lucas Francisco Delgado Duarte < [email protected]> escreveu: > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAMTDOVqwBmxpfV6HJZxysnKPddYkpMzkGMS%2B%3DX2-zj41nNGyXg%40mail.gmail.com.
