The REST authentication issue has been addressed in SwitchYard 2.0, but that solution will still authenticate on every request if SY security policy is used. Introducing a valve is an interesting approach to externalize the authentication and take advantage of container support, but I have not looked into that in detail.
Ah, apparently I misunderstood how the SingleSignOn valve worked. I assumed it short circuited the authentication process somehow but instead it merely reinjects the authentication parameters. So since the REST authentication issue isn't fixed until 2.0, the REST call still won't work even though the username/password are successfully on the request.
On the other hand, refreshing the access restricted html page hits the SingleSignOn valve but does not reach the domain login--so it did short circuit the login with every request in some way. Is that just a difference in implementation in security policy and the SY environment cannot mimic it?
SY's security handling code intercepts every incoming request. If a clientAuthentication security policy is in place, the incoming credentials are re-evaluated each time. Specifically, the configured JBoss LoginModule stack is invoked. Even in the case of SAML tokens, the assertions are at least validated by the LoginModule stack. The only time this stack is not triggered is if one SY service calls another SY service, such that the SY security context can be propagated, and a boundary is not crossed. By "boundary" I mean differing security domains, different OS processes, a network hop, or time (as the SY security context can be configured to expire).