Benutzerdefinierte Anforderungsbehandlung bei Einzelanmeldung fehlgeschlagen

Question

Ich verwende WSO2 Identity Server für Single Sign On-Implementierungen.

In meinen Demo-Anwendungen versuche ich benutzerdefinierte Anspruch Attribute von authentifizierten Benutzer aus meiner eigenen JDBC-Datenbank zu erhalten.

Ich folgte dieser blog von Pushpalanka.

Dieser arbeitete für den Identity Server 5.0.0

gut, aber wenn ich Identity Server mit dem neuesten Update-"WSO2-IS-5.0.0-SP01" aktualisiert, Handhabung Individuellen Anspruchs funktionierte nicht mehr.

folgend ist der Fehler-Stack:

[2015.04.22 19: 09: 43.311] ERROR { org.wso2.carbon.identity.application.authentication.framework.handler.sequence.impl .DefaultStepBasedSequenceHandler} - Fehlerbehandlung fehlgeschlagen! org.wso2.carbon.identity.application.authentication.framework.exception.FrameworkException: Index: 0, Größe: 0 at com.wso2.sample.claim.handler.CustomClaimHandler.handleLocalClaims (CustomClaimHandler.java:200) um com.wso2.sample.claim.handler.CustomClaimHandler.handleClaimMappings (CustomClaimHandler.java:66) bei org.wso2.carbon.identity.application.authentication.framework.handler.sequence.impl.DefaultStepBasedSequenceHandler.handleClaimMappings (DefaultStepBasedSequenceHandler. Java: 604) bei org.wso2.carbon.identity.application.authentication.framework.handler.sequence.impl.DefaultStepBasedSequenceHandler.handlePostAuthentication (DefaultStepBasedSequenceHandler.java:394) bei org.wso2.carbon.identity.application.authentication.framework.handler.sequence.impl.DefaultStepBasedSequenceHandler.handle (DefaultStepBasedSequenceHandler.java:134) unter org.wso2.carbon.identity.application.authentication.framework.handler. request.impl.DefaultAuthenticationRequestHandler.handle (DefaultAuthenticationRequestHandler.java:121) bei org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator.handle (DefaultRequestCoordinator.java:94) bei org.wso2.carbon.identity.application.authentication.framework.servlet.CommonAuthenticationServlet.doPost (CommonAuthenticationServlet.java:54) unter javax.servlet.http.HttpServlet.service (HttpServlet.java:755) um javax.servlet. http.HttpServle T.SERVICE (HttpServlet.java:848) bei org.eclipse.equinox.http.helper.ContextPathServletAdaptor.service (ContextPathServletAdaptor.java:37) bei org.eclipse.equinox.http.servlet.internal.ServletRegistration.service (ServletRegistration.java:61) bei org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias ​​(ProxyServlet.java:128) bei org.eclipse.equinox.http.servlet.internal.ProxyServlet.service (ProxyServlet.java:60) bei javax.servlet.http.HttpServlet.service (HttpServlet.java:848) um ​​ org.wso2.carbon.tomcat.ext.servlet.DelegationServlet.service (DelegationServlet.java:68) unter org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:305) bei org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:210) bei org.wso2.carbon.tomcat.ext.filter.CharacterSetFilter.doFilter (CharacterSetFilter.Java: 61) bei org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:243) bei org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:210) bei org .apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:222) bei org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:123) bei org.apache.catalina.authenticator.AuthenticatorBase .invoke (AuthenticatorBase.java:472) um org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:171) um org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:99) bei org.wso2.carbon.tomcat.ext.valves.CompositeValve.continueInvocation (CompositeValve.java:178) bei org.wso2 .carbon.tomcat.ext.valves.CarbonTomcatValve $ 1.invoke (CarbonTomcatValve.java:47) bei org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke (TenantLazyLoaderValve.java:56) bei org.wso2. carbon.tomcat.ext.valves.TomcatValveContainer.invokeValves (TomcatValveContainer.java:47) bei org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke (CompositeValve.java:141) bei org.wso2. carbon.tomcat.ext.valves.CarbonStuckThreadDetectionVa lve.invoke (CarbonStuckThreadDetectionValve.java:156) bei org.apache.catalina.valves.AccessLogValve.invoke (AccessLogValve.java:936) bei org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.invoke (CarbonContextCreatorValve.java:52) bei org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:118) bei org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:407) bei org.apache.coyote.http11.AbstractHttp11Processor.process (AbstractHttp11Processor.java:1004) bei org.apache.coyote.AbstractProtocol $ AbstractConnectionHandler.process (AbstractProtocol.java:589) bei org.apache.tomcat.util.net.NioEndpoint $ SocketProcessor.run (NioEndpoint.java:1653) bei java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1145) bei java.util .concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:615) bei java.lang.Thread.run (Thread.java:745) Verursacht von: java.lang.IndexOutOfBoundsException: Index: 0, Größe: 0 um java.util.ArrayList.rangeCheck (ArrayList.java:635) unter java.util.ArrayList.get (ArrayList.java:411) unter org.wso2.carbon.claim.mgt.ClaimManagerHandler.validateClaims (ClaimManagerHandler.java: 668) unter org.wso2.carbon.claim.mgt.ClaimManagerHa ndler.getMappingsFromOtherDialectToCarbon (ClaimManagerHandler.java:529) bei org.wso2.carbon.claim.mgt.ClaimManagerHandler.getMappingsMapFromOtherDialectToCarbon (ClaimManagerHandler.java:614) bei com.wso2.sample.claim.handler.CustomClaimHandler.handleLocalClaims (CustomClaimHandler.java:141).

Nach meiner Studie über Quellcode Identity Server dieses Problem ist in Authentifizierungs-Framework bei org.wso2.identity.application.authentication.framewotk Komponente.

Das Problem könnte in der Validierung von Ansprüchen sein, aber ich habe keine Methode namens validateClaims im Quellcode gefunden.

Im Quellcode im Blogpost Authentication Framework Version - 4.2.2 wird verwendet.

Ich habe versucht, mit der neuesten Version von Authentication Framework - 4.2.3.

Aber das Problem ist immer noch in der gleichen Komponente.

Ich gebe immer noch meine Bemühungen dazu. Ich brauche eine Anleitung dazu.

Bitte jemand helfen, wenn ich etwas vermisse oder jemand von Ihnen das gleiche Problem konfrontiert haben.

Danke.

Answer 1

Ich sehe häufig Probleme mit benutzerdefinierten Modulen auch zwischen kleineren Versionsupdates. Selbst jetzt sehe ich, dass unser benutzerdefinierter Authentifikator nach dem noch nicht veröffentlichten Patch möglicherweise nicht funktioniert. Brauchen Sie wirklich eine benutzerdefinierte Schadenbearbeitung?

Wir haben den Claim-Dialekt für Ansprüche und Attribute erweitert, die an den Service-Provider zurückgegeben werden müssen, und die Standard-Framework-Implementierung liest und user/gibt die angeforderten Benutzerattribute zurück. Für die meisten Fälle sollte es reichen.