30
votes

I am using the WSO2 Identity Server for Single Sign-On Implementations.

In my demo applications, I am trying to get Custom claim attributes of authenticated Users from my own JDBC Database.

I followed this blog of Pushpalanka.

This worked fine for the Identity Server 5.0.0

But when I updated Identity Server with the latest Update "WSO2-IS-5.0.0-SP01", Custom Claim Handling stopped working.

Following is the error stack :

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

According to my study on the source code of Identity Server this problem is in the Authentication Framework at org.wso2.identity.application.authentication.framework component.

The problem might be in validating claims but I didn't found any method named validateClaims in the source code.

In the source code given in the blog post, Authentication Framework version - 4.2.2 is used.

I tried using the latest version of Authentication Framework - 4.2.3.

But the problem is still in the same component.

Am I missing something?

1

1 Answers

0
votes

I see commonly problem with custom modules even between minor version updates. Even now I see our custom authenticator may not work after the not-yet-issued patch. Do you really need custom claim handling?

We have extended the claim dialect for claims and attributes needed to be returned to the service provider and the default framework implementation will read and user/return the requested user attributes. For most of the cases it should be enough.