Hi, Anise. Could you elaborate a bit what is idea of your script, what goal you're trying to achieve? So far I'm not sure whether you are trying to report a bug, or just can't understand Gluu's innerworkings. Both `getAuthenticationMethodClaims()` and `setAmrClaim()` doesn't seem like standard interfaces accessible from auth script. Are you experimenting by changing Gluu's source code? Usually such topics are not covered by community support. Though you could try to share your code and explain it in more details, may be somebody will provide some suggestions on your case.

Hi Aliaksandr, I'm just trying to pass a value from authenticate() to getAuthenticationMethodClaims() in my auth script. I haven't modified the source code, just using the .war file that Yuriy provided for me in my previous thread: https://support.gluu.org/authentication/4293/setamrclaim-in-idtokenfactoryjava-only-allows-scripts-with-usage-type-of-both-methods-instead-of-allowing-scripts-of-any-type/#at23848 The latter method is supported, it was added for the purpose of adding amr values in the ID token. The setAmrClaim() method calls it, but I noticed the qtp number changes first for getApiVersion(), which is called immediately before getAuthenticationMethodClaims() in the method, so that's why I thought maybe the thread is changing sometime when setAmrClaim() is called. I just happened to notice that Yuriy fixed a bug a few hours ago here: https://github.com/GluuFederation/oxAuth/issues/588 I could be mistaken, but that sounds like it might be related to the same issue I am having (issues with custom script and multiple threads). Anyway, just let me know if you require any additional info from me. Thanks!

Hi, Anise. >I just happened to notice that Yuriy fixed a bug a few hours ago here: https://github.com/GluuFederation/oxAuth/issues/588 I'll let Yuriy answer this then. Still I would suggest to quote here corresponding part of your custom script where those functions are called and explain your goals, to provide a context.

Here is some additional info, in case it helps: For now, I am using the basic username/password combo to authenticate, but I also pass a user-inputted number in the login form (simply called loginValue). I want to pass this value in the amrclaims in the IdToken, back to the Relying Party server. In my authenticate() method, I retrieve the loginValue from the requestParameters, then set it in the context, as such: ``` context = Contexts.getEventContext() loginValue = requestParameters.get("loginForm:loginValue")[0].strip() context.set("loginValue", loginValue) ``` Here is the oxauth_script.log output, after logging in with a user-inputted loginValue of 95: ``` 2017-07-14 17:58:12,067 INFO [qtp242131142-10] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic. authenticate() for step = 1 2017-07-14 17:58:12,097 INFO [qtp242131142-10] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic - authenticate(), loginValue = 95 2017-07-14 17:58:12,098 INFO [qtp242131142-10] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic - authenticate(), context = array(java.lang.String, [u'org.jboss.seam.core.manager', u'javax.servlet.forward.context_path', u'javax.servlet.forward.servlet_path', u'org.jboss.seam.faces.validation', u'loginValue', u'javax.servlet.forward.request_uri', u'org.jboss.seam.ui.clientUidSelector', u'authenticatedUser', u'com.sun.faces.context.ExternalContextFactoryImpl_KEY', u'org.jboss.seam.core.conversationPropagation', u'org.jboss.seam.core.events', u'org.jboss.seam.web.servletContexts', u'org.jboss.seam.web.requestContextPath', u'sessionAttributes', u'authenticator', u'org.jboss.seam.web.requestServletPath']) 2017-07-14 17:58:12,098 INFO [qtp242131142-10] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic. getApiVersion() = 4 2017-07-14 17:58:12,098 INFO [qtp242131142-10] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic - getApiVersion(). loginValue = 95 2017-07-14 17:58:12,099 INFO [qtp242131142-10] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic. getNextStep() 2017-07-14 17:58:12,099 INFO [qtp242131142-10] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic. getExtraParametersForStep() 2017-07-14 17:58:12,100 INFO [qtp242131142-10] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic. getCountAuthenticationSteps() 2017-07-14 17:58:12,100 INFO [qtp242131142-10] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic - getCountAuthenticationSteps(). loginValue = 95 2017-07-14 17:58:12,199 INFO [qtp242131142-11] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic. getApiVersion() = 4 2017-07-14 17:58:12,200 INFO [qtp242131142-11] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic - getApiVersion(). loginValue was NOT found in context. 2017-07-14 17:58:12,201 INFO [qtp242131142-11] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic. getAuthenticationMethodClaims() 2017-07-14 17:58:12,201 INFO [qtp242131142-11] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic - getAuthenticationMethodClaims(), loginValue was NOT found in context, setting to 1. 2017-07-14 17:58:12,201 INFO [qtp242131142-11] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:219) - Basic - getAuthenticationMethodClaims(), amr: {'loginValue': '1'} ``` As you can see, the loginValue is accessible via the context all the way up to the second call to getApiVersion (which is done in setAmrClaim() in IdTokenFactory.java). This is also the point where the qtp number changes from 10 to 11, so it looks like the getAuthenticationMethodClaims() method is no longer able to access the loginValue, since it is running in qtp 11 (and the loginValue was saved in qtp 10 context). EDIT: Just in case the logging caused some confusion - I'm basically just printing when one of the custom script methods is entered, and accessing the loginValue along the way, just to see when it could no longer be accessed anymore. Please don't hesitate to contact me if you require any additional info. Thank you!

So, after some digging around, it makes sense why the previous context is inaccessible from getAuthenticationMethodClaims (and the second call to getApiVersion), called from setAmrClaim()). The authentication process is done at that point, and this is being called when creating the ID Token, upon getting a UserInfo request from the Relying Party. So, following the documentation here: https://gluu.org/docs/ce/authn-guide/customauthn/ and using context.set() no longer works in the case of getAuthenticationMethodClaims(), because it's on a different thread, running after the actual authentication process is complete. So basically, I'm wondering if there's any possible way to pass a value (taken from the requestParameters for now, just as an example) from the authenticate() method in my script to the getAuthenticationMethodClaims() method. The documentation describes that context.set() passes "the session attribute value to LDAP by creating a temporary attribute which has a limited lifetime and can be retrieved within the life span, otherwise it expires and the session becomes invalid." So can I save the loginValue (described in my previous post) in LDAP during the authentication process, long enough (let's say 5 seconds) to be accessed by getAuthenticationMethodClaims() during the UserInfo request by the Relying Party? Or is this currently not possible (in which case I'd have to look into modifying the Gluu source code)? Thanks in advance.

Just for future reference, in case anyone wants to do the same thing - I accomplished this by creating a custom attribute in LDAP (and registering it in Gluu, per the documentation), and updating the attribute during the authentication process by using the various methods in UserService.java. I'll close this ticket now, though there should probably be a note added to the custom script documentation page that using context.set() won't work for passing data to getAuthenticationMethodClaims(), due to the reasons I outlined above.

Yes, using internal LDAP server for persistence and saving/passing states is a most solid option to rely upon, oxAuth uses it itself intensively. I thought you may have some considerations to have it your way, so didn't mention it, it seems like you know your ways around Gluu's innerworkings well enough. >I'll close this ticket now, though there should probably be a note added to the custom script documentation page that using context.set() won't work for passing data to getAuthenticationMethodClaims(), due to the reasons I outlined above. May be Yuriy still will have some time to comment here and give his conlcusion. I'll see what can be done otherwise. Thank you a lot for your time and effort, Anise!