Switchyard clientAuthentication session?

[mayerathome]

How do I go about getting a persistent clientAuthentication session with switchyard?

I'm creating SPA with a form login page and lots of ajax REST queries to the back end.  I'd like to only have to log in once and not have the client hold on to password information and authenticate with each request.ord information to continually authenticate.  And it's SOA so I'd like to be authenticated to all of the switchyard services.

I was able to configure a JAAS security domain in my jboss environment and was able to log in to both a switchyard service as well as a form based html using that domain.  The next hurdle was to get it to remember my authentication status since every subsequent REST query to Switchyard wanted to re-authenticate me.

• I tried connecting to a switchyard service within the same war as my form based jsp that authenticated but it still wanted authentication.

• I tried turning on SSO in by updating standalone.xml to have the following subsystem:

<subsystem xmlns="urn:jboss:domain:web:1.4" default-virtual-server="default-host" native="false">

      <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>

      <virtual-server name="default-host" enable-welcome-root="true">

      <alias name="localhost"/>

      <sso domain="localhost" reauthenticate="false"/>

      </virtual-server>

</subsystem>

And updating my war’s jboss-web.xml to include:

              <valve>

                    <class-name>org.apache.catalina.authenticator.SingleSignOn</class-name>

             </valve>

Is there another piece that needs to be configured so that the  Switchyard Runtime knows about already authenticated users?

Even if I had the client hold onto username/password, it looks like I wouldn’t be able to since REST can’t authenticate currently: https://issues.jboss.org/browse/SWITCHYARD-1864

[kcbabo]

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.

[mayerathome]

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?

[dward]

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).