ACS sessions

Question

in our world (US realty) we exploit a notion of early SAML, called SP affiliations. Since hardly any SAML implementations support it, we have to make do - and implement the idea (rather than the protocol).

It affects ACS, and its role.

Assume that user has landed on 1 of several spokes in a community (e.g. realty). The spoke does sp-initated websso, using ACS as the broker, perhaps having indicated with IDP to use.

 

If another site to which the same browser connects makes a similar request, will the the IDP be pinged or not? I.e. does ACS itself have a session?

 

Assuming ACS has no session (acting as a pure protocol relay), I will be using one of our SPs as a master-session manager, for a group of SPs. Obviously, having received an assertion from ACS to mint the master session, this broker will be an ACS-like broker in its own right, willing to act as an asserting part to its affiliated network of SPs.

 

We have been doing SSO on a (US) national scale for 5 years with 125 tenants and 50 or more spokes per hub, and have learned what users sites doing mashups REALLY want, when they span social and enterprise trust networks doing websso! We didnt opt for the facebook model, but kept things entirely de-centralized, leveraging such as ACS when its a nice protocol gateway (vs a party attempt to be a governing entity).

 

 

 

Answer 1

Hi Peter,

As far as I know, ACS has no session. However, after validating the token the RP can keep session with the client for SSO purpose.

Thanks,

---

Wengchao Zeng
Please mark the replies as answers if they help or unmark if not.
If you have any feedback about my replies, please contact [e-mail].
Microsoft One Code Framework

Answer 2

ok. Let me discuss a little more, then formulate more specific questions - since that evidently the preferred style of MSDN forums.

Lets assume I choose to configure ACS to mint a SAML2 token (to be borne back to the RP using a ws-fedp protocol run, vs a SAML2 protocol run)

In this flow, the RP sends a request bearing idp-identifier to ACS (which thus proxies the request to the nominated IDP). The IDP's response (a SAML1 token say) will be proxied by ACS back to the RP, after claims transformation and SAML2 token rewriting.

If, for some reason, the RP sends exactly the same request again a second later, ACS will perform exactly the same actions as above (from your initial response). The IDP may well behave differently, and probably will do becuase it maintains an IDP session for the user. This non-ACS matter wil probably enable the user to avoid a challenge on the second run.

ACS will not, for example, for the second case, "reissue" the "same" token as returned in the first round, bearing the same session identifier in the SAML2 token as was used earlier.

Q: is it true that the SAML2 token from ACS does not implement the semantics of authentication statements and its sessionindex field specifically (see

http://msdn.microsoft.com/en-us/library/microsoft.identitymodel.tokens.saml2.saml2authenticationstatement.sessionindex.aspx)

 

This is relevant to those RPs using ACS which are not built upon WIF libraries. (WIF libraries will no doubt take care of these issues, as intended by the ACS use cases). Non-WIF ws-fedp relying parties interworking with ACS need to know the session semantics the ACS upholds, when acting as an FP. As an FP, issuing an SAML2 token, it may or may not be implementing, formally, the SAML2 "IDP proxy" use case (or similar) - which impacts the sessionindex value. It may just be borrowing the SAML2 format while not implementing all the fields per their use in the various SAML2 "protocols". After all, this is a ws-fedp protocol's profile of the genric SAML2 format type, not the SAML2 protocol's profile (of the SAML2 assertion type).

 

Q: is there anything an IDP can do in formulating the token to be returned to ACS to enable ACS to populate the sessionIndex field within the SAML2 token it asserts to the requesting RP?

Q: is there anything an IDP can do in formulating the token to be returned to ACS to enable ACS to return the same sessionIndex field within the SAML2 token it asserts to the requesting RP, for the life of the (initial) SAML2 token?

I assume the answers to the 3 Qs will be 3 no responses. But, its worth confirming the details, I feel. Its all relevant to deciding how well ACS fits into a mature websso world, or not; one built around the session semantics of SAML2. It helps understand what role it might play, and what role other websso-related agents must continue to play.

 

Answer 3

Most of the questions raised here are not within scope with ACSv2 so answering those question are not applicable. The answers to these questions is mostly no as they are not in the current design framework. If you require more help, please consider opening a support case with us. Visit this link to see the various support options that are available to better meet your needs: https://support.microsoft.com/oas/default.aspx?&c1=501&gprid=14928&&st=1&wfxredirect=1&sd=gn .

---

--Trevor H.
Send files to Hotmail.com: "MS_TREVORH"

Answer 4

Fair enought. Its probably not in the remit of a support forum to make products interwork with other vendors implementations of the same protocol. thats the duty of the development or QA group.

Ive suggested to the Shibboleth group that they do an interworking trial with ACS. I doubt it will happen; and I doubt the ACS can send tokens to Shib over ws-fedp that Shib will then process. This will limit the applicability of ACS in an academic world, of course.

 

I managed to fix an "ADFS" plugin to joomla, allowing ACS to interwork with the joomla SP. It was a 3 line fix in php, allowing the token processor in joomla to recognize the presence of a nameid field in an AttributeStatement. The fix modified the previous code that required the same nameid to be present in an AuthenticationStatement. So, we now have a multi-vendor interworking success, I suppose - once the token procesor allows a nameid in either the attribute or the authentication statement. I was hoping that someone here would know how to configure ACS so it always provides an authenticationStatement.

 

Ive asked Ping Identity to consider making an interoperability trial of their latest "WIF+capable" server to act as an SP and interwork with ACS. As it stands, an obvious interworking does not work. The lack of authenticationstatement trips up PingFederate SP, inducing an exception. Strangely, where an ADFS Identity provider is configured with ACS (vs an PingFederate IDP), the PingFederate SP does not trip up. This is because when ACS uses ADFS as an identity provider, ACS populates the AuthenticationStatement.

I doubt anyone try it, but for a couple of days here is an example of a failure that one would not expect to fail. Its a demonstration of multi-vendor interworking failure. Evidently, the Ping Identity SP server is (like joomla) just not programmed to expect a missing authenticationStatement. Thus, it does not obviously interwork with ACS (though it interworks with ADFS just fine). Ive asked Ping Identity for documentation on product interacting with WIF idps, and ACS specfically.

https://pingcertification.rapattoni.com/quickstart-app-sp/go?action=sso&PartnerIdpId=https%3A%2F%2Fjhogan.accesscontrol.windows.net%2F

I amazed that these issues didnt get picked up upon during the beta period of ACS v2, on the dev site.