36

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?

Community
  • 1
  • 1
Tilakraj Jayswal
  • 471
  • 4
  • 10

1 Answers1

0

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.

gusto2
  • 11,210
  • 2
  • 17
  • 36
  • Yeah - reading user attributes from additional / extra data source(s) is not always simple. We've created a custom userstore manager, authenticating with the primary LDAP and reading attributes from another source (AD) overwriting getUserPropertyValues method. – gusto2 Apr 29 '15 at 09:52
  • And you are right, user roles needs to be handles separately. However - we tried to keep it simple and do it on the user store level (of cause there are some limitations too).. – gusto2 Apr 29 '15 at 09:55
  • 1
    Yes, that will be enough in the case when the user store from which we are getting the claims is configured as a primary/secondary in Identity server. But there are some other issues when I am adding secondary user stores. e.g ActiveDirectory. When I am adding ActiveDirectory as a secondary user store, all the users are not getting internal/everyone role by default. So we have to manually go to users and assign roles. Also this works for only one active session. So, Its better to have Custom claim Handler rather than attaching the user store with Identity server as a secondary user store. – Tilakraj Jayswal Apr 29 '15 at 09:56
  • Adding secondary user store doesn't help in this case at all. As user is authenticated in the user store, attributes of the user store identity are used. The idea was - provide the user attributes from another LDAP (configured in additional user store properties), but for IS it acts as a single user store. With custom claim management you chose different way to achieve that, maybe even more flexible. Apparently the interfaces has changed between versions (WSO2 !!! Keep the interfaces stable!) . Wouldn't help to extends the default claim handler rather than implement the interface? – gusto2 Apr 29 '15 at 10:44
  • Another Solution : If we authenticating the user from the user store which is configured with Identity server, then we can get claims by Mgt UI as well. Use Wso2 provided default claim dialects. as e.g http://wso2.org/claims. Add claim mapping to that dialect. as e.g http://wso2.org/claims/appUrl. here appUrl - attribute from user store table. and add that claim to the claim configuration section of your SP registration. you will see the claims returned in SAML response. worked for me :) requirement : user should get authenticated from the user store from where you want claims to be returned – Tilakraj Jayswal Apr 29 '15 at 11:25
  • It looks like there is an issue with the `CustomClaimHandler` in WSO2 Identity Server 5.0.0-SP01. In line 200 of the CustomClaimHandler.java file, there is an attempt to access an element of a list with an index that is out of bounds. This is what is causing the error message you are seeing. Maybe a bug in the `CustomClaimHandler` code, or it could be an issue with the data being accessed. In any case, it seems that there is a problem with how the code is handling the list of claims. – thatthing Dec 03 '22 at 21:10