Niestandardowa obsługa roszczeń nie powiodła się przy jednokrotnym zalogowaniu

Question

Używam serwera tożsamości WSO2 do implementacji pojedynczego logowania.

W moich aplikacjach demonstracyjnych próbuję uzyskać niestandardowe atrybuty roszczenia uwierzytelnionego użytkownika z mojej własnej bazy danych JDBC.

Poszedłem za tym blog z Pushpalanka.

To działało w porządku dla Identity Server 5.0.0

Ale kiedy aktualizowane Identity Server z najnowszej Aktualizacji "WSO2-is-5.0.0-SP01", niestandardowe Roszczenie obchodzenia przestał działać.

Poniżej stos błąd:

[22.04.2015 19: 09: 43311] Błąd {org.wso2.carbon.identity.application.authentication.framework.handler.sequence.impl .DefaultStepBasedSequenceHandler} - Obsługa roszczeń nie powiodła się! org.wso2.carbon.identity.application.authentication.framework.exception.FrameworkException: Indeks: 0, Rozmiar: 0 na com.wso2.sample.claim.handler.CustomClaimHandler.handleLocalClaims (CustomClaimHandler.java:200) w com.wso2.sample.claim.handler.CustomClaimHandler.handleClaimMappings (CustomClaimHandler.java:66) w org.wso2.carbon.identity.application.authentication.framework.handler.sequence.impl.DefaultStepBasedSequenceHandler.handleClaimMappings (DefaultStepBasedSequenceHandler. Java: 604) w org.wso2.carbon.identity.application.authentication.framework.handler.sequence.impl.DefaultStepBasedSequenceHandler.handlePostAuthentication (DefaultStepBasedSequenceHandler.java:394) w org.wso2.carbon.identity.application.authentication.framework.handler.sequence.impl.DefaultStepBasedSequenceHandler.handle (DefaultStepBasedSequenceHandler.java:134) pod adresem org.wso2.carbon.identity.application.authentication.framework.handler. request.impl.DefaultAuthenticationRequestHandler.handle (DefaultAuthenticationRequestHandler.java:121) w org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator.handle (DefaultRequestCoordinator.java:94) w org.wso2.carbon.identity.application.authentication.framework.servlet.CommonAuthenticationServlet.doPost (CommonAuthenticationServlet.java:54) w javax.servlet.http.HttpServlet.service (HttpServlet.java:755) pod adresem javax.servlet. http.HttpServle t.service (HttpServlet.java:848) pod adresem org.eclipse.equinox.http.helper.ContextPathServletAdaptor.service (ContextPathServletAdaptor.java:37) pod adresem org.eclipse.equinox.http.servlet.internal.ServletRegistration.service (ServletRegistration.java:61) w org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias ​​(ProxyServlet.java:128) w org.eclipse.equinox.http.servlet.internal.ProxyServlet.service (ProxyServlet.java:60) w javax.servlet.http.HttpServlet.service (HttpServlet.java:848) pod adresem org.wso2.carbon.tomcat.ext.servlet.DelegationServlet.service (DelegationServlet.java:68) pod adresem org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:305) w org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:210) w org.wso2.carbon.tomcat.ext.filter.CharacterSetFilter.doFilter (CharacterSetFilter.Java: 61) w org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:243) w org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:210) w org .apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:222) w org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:123) w org.apache.catalina.authenticator.AuthenticatorBase .invoke (AuthenticatorBase.java:472) pod adresem org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:171) pod adresem org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:99) w org.wso2.carbon.tomcat.ext.valves.CompositeValve.continueInvocation (CompositeValve.java:178) w org.wso2 .carbon.tomcat.ext.valves.CarbonTomcatValve $ 1.invoke (CarbonTomcatValve.java:47) na org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke (TenantLazyLoaderValve.java:56) na org.wso2. carbon.tomcat.ext.valves.TomcatValveContainer.invokeValves (TomcatValveContainer.java:47) w org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke (CompositeValve.java:141) w org.wso2. carbon.tomcat.ext.valves.CarbonStuckThreadDetectionVa lve.invoke (CarbonStuckThreadDetectionValve.java:156) w org.apache.catalina.valves.AccessLogValve.invoke (AccessLogValve.java:936) w org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.invoke (CarbonContextCreatorValve.java:52) w org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:118) w org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:407) w org.apache.coyote.http11.AbstractHttp11Processor.process (AbstractHttp11Processor.java:1004) pod org.apache.coyote.AbstractProtocol $ AbstractConnectionHandler.process (AbstractProtocol.java:589) w org.apache.tomcat.util.net.NioEndpoint $ SocketProcessor.run (NioEndpoint.java:1653) w java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1145) na java.util .concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:615) w java.lang.Thread.run (Thread.java: 745) Spowodowane przez: java.lang.IndexOutOfBoundsException: Index: 0, Rozmiar: 0 at java.util.ArrayList.rangeCheck (ArrayList.java: 635) pod adresem java.util.ArrayList.get (ArrayList.java: 411) pod adresem org.wso2.carbon.claim.mgt. ClaimManagerHandler.validateZgłoszenia (ClaimManagerHandler.java: 668) pod adresem org.wso2.carbon.claim.mgt.ClaimManagerHa ndler.getMappingsFromOtherDialectToCarbon (ClaimManagerHandler.java:529) w org.wso2.carbon.claim.mgt.ClaimManagerHandler.getMappingsMapFromOtherDialectToCarbon (ClaimManagerHandler.java:614) w com.wso2.sample.claim.handler.CustomClaimHandler.handleLocalClaims (CustomClaimHandler.java:141).

Według moich badań nad kodem źródłowym Identity Server Problem ten jest w Authentication Framework w składniku org.wso2.identity.application.authentication.framewotk.

Problem może dotyczyć sprawdzania poprawności oświadczeń, ale nie znalazłem żadnej metody o nazwie validateClaims w kodzie źródłowym.

W kodzie źródłowym podanym w poście na blogu użyto wersji Authentication Framework - 4.2.2.

Próbowałem używać najnowszej wersji Podstawy uwierzytelniania - 4.2.3.

Ale problem nadal występuje w tym samym komponencie.

Nadal staram się o to. Potrzebuję wskazówek na ten temat.

Proszę, pomóż komuś, jeśli coś mi brakuje, albo którykolwiek z was zmierzył się z tym samym problemem.

Dzięki.

Answer 1

Widzę często problem z niestandardowymi modułami, nawet między mniejszymi aktualizacjami wersji. Nawet teraz widzę, że nasz autentykator może nie działać po nie wydanej jeszcze łatce. Czy naprawdę potrzebujesz niestandardowej obsługi roszczeń?

Rozszerzyliśmy dialekt oświadczenia o roszczenia i atrybuty potrzebne do zwrócenia usługodawcy, a domyślna implementacja ramowa odczyta i użytkownika/zwróci wymagane atrybuty użytkownika. W większości przypadków powinno wystarczyć.