[
http://java.net/jira/browse/JASPIC_SPEC-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=357176#action_357176 ]
monzillo commented on JASPIC_SPEC-9:
------------------------------------
I assigned this to the tck team. I think it would help to check compatibility for this requirement.
what you are doing is also a great help, in that you are pointing out where the problems are, and
hopefully the product engineers will be working to fix this product. If you have a way to create an
issue in their issue trackers that would also help (or send us any info you have on where such info
could be entered)
> Clarify and/or add TCK test for validateRequest/invoke service/secureResponse ordering
> --------------------------------------------------------------------------------------
>
> Key: JASPIC_SPEC-9
> URL: http://java.net/jira/browse/JASPIC_SPEC-9
> Project: jaspic-spec
> Issue Type: New Feature
> Reporter: arjan tijms
> Assignee: phendley
>
> Section 3.8.2.2 of the JASPIC spec discusses the invocation of {{validateRequest}} after a service invocation for the Servlet Container Profile.
> It does however not give any details under which circumstances the runtime should call this method _after_ a service invocation, and neither does it give any details about how an implementation of this method should distinguish between being called before service invocation (in which its job is to do authentication) and after service invocation (in which its job is to secure a response). For the SOAP profile, footnote 6 in 4.9.5.3 _does_ give an explanation.
> Section 3.8.3.3 says that the semantics of {{secureResponse}} are as defined in Section 3.8.2.2, which thus means that {{secureResponse}} should be called _after_ a service invocation. Figure 1.1 in Section 1.1 shows this as well, and the general flow as described is Section 3.8 also mentions this.
> Unfortunately, not all JASPIC implementations indeed call {{secureResponse}} after a service invocation. GlassFish 3.1.2.2, Geronimo V3.0 and WebSphere 8.5 do make the call afterwards, but the certified implementations of JBoss EAP 6.0.1 (and AS 7.1.1) as well as WebLogic 12.1.1 call {{secureResponse}} before a service invocation. In fact, both those implementations call {{secureResponse}} nearly immediately after {{validateRequest}} is called. In case of WebLogic 12.1.1 this can be deduced from the call stack in debug mode, while in case of JBoss EAP 6.0.1 it can be seen directly in its source code.
> E.g. consider the following abbreviated excerpt from JBoss EAP's {{WebJASPIAuthenticator}}:
> {code}
> GenericMessageInfo messageInfo = new GenericMessageInfo();
> messageInfo.setRequestMessage(request);
> messageInfo.setResponseMessage(request.getResponse());
> // [...]
> ServerAuthenticationManager sam = getServerAuthenticationManager();
>
> if (sam != null) {
> // Calls through to validateRequest on SAM
> result = sam.isValid(messageInfo, clientSubject, messageLayer, appContext, cbh);
> }
> if (result) {
> // [Jboss specific login]
> if (this.secureResponse)
> // Calls through to secureResponse on SAM
> sam.secureResponse(messageInfo, new Subject(), messageLayer, appContext, cbh);
> }
> }
> return result; // Service invocation will happen after this if result == true
> {code}
> In case of JBoss EAP, {{secureResponse}} is not only seemingly called at the wrong time, it's also an optional operation (default false) but the spec does not mention this operation to be optional.
> I would like to request a TCK test to be added that tests that {{secureResponse}} is indeed called after a service invocation, and clarification of the following items:
> * 3.8.2.2 - Why or when would {{validateRequest}} be called after a service invocation
> * Perhaps in 3.8.3.3 an explicit statement that {{secureResponse}} is to be called after a service invocation and not before.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira