Making Azure ACS send RP's realm to IDP in wtrealm in WS-federation

Question

Hi,

I have a custom IDP which support WS-federation. And I have to do quite a few integrations.

As part of an integration we want to send some data across to the application on Azure. My IDP picks up the data to be passed based on wtrealm field. When I integrate with ACS, ACS passes it's own URL as the realm. So if there are 3 RPs configured in that ACS namespaces, for all the 3 RPs I get only the ACS realm, and I cannot provide specific information for the application.

 Can I make ACS pass the end application's realm in the wtrealm field , and keep the wreply field to ACS?

Thanks and Regards,

Kanduri

---

Thanks and Regards, Kanduri

Answer 1

What you're asking for is counter to the WS-Federation specification. The wtrealm passed by ACS indicates the audience of the token it expects in return, so that value must be ACS. You're only supposed to federate with your neighbor. Can the data you want to add be added via rules in ACS?

If rules don't help you, you could retrieve the login URL for each IdP using the Home Realm Discovery feed (identityproviders.js) and modify the wtrealm value as needed. As long as the token audience back to ACS is correct, ACS will never know the difference. However, this would be nonstandard.

Answer 2

just create 3 ACS namespaces... binding 1 RP to each.

Answer 3

Hi,

 We are looking at this model. But if there are 100 apps coming up, should I use 100 name spaces?

Something doesn't sound quite right.

---

Thanks and Regards, Kanduri

Answer 4

Hi Oren,

 Rules definitely don't help me here as the data has to come from the IDP.

I thought the HRD only speaks about the IDP URLs. What I need is the RP URL in the wtrealm.

---

Thanks and Regards, Kanduri

Answer 5

are they really 100 app, or are thye 100 resources (being guarded by 3 or n apps)?

what is an app, what is a resource-set?

Remember, SP entityIDs are not your only tool to built the switching network (and thats how to think of it)

Could you could have 1 app and 100 resources split into 3 sets , with such sets segmented by role in the claimset  from the authoried IDPs?

In this case, think of the IDP-SP "bridge" as multiplexor of claims "channels" that run end-end from user to resource-under-protection.

One could build n bridges, 1 per end-end control objective. Or, there is 1 bridge, over which coded signals pass ready to be decoded (i.e. demuliplexed) by a guard built into the app (not built into the SP).

I dont agree with the deign comment by someone that what you asked for originally is not per the ws-fedp model. The model actualy does allow for the notion of virtual-SP entities, and different endpoint per SP entityID (virtual or not). At the same time, realize that a namespace in ACS is a virtual-SP (in all but terminology). If one buys into my argument that one does use ws-fedp where virtual SP entityIDs are a fundmanetal architectural construct, then realize ACS is perfect for that (being one giant virutalizer of SPs endpoints, called a namespace).

Remember, switching is now virtualized. You dont buy 100 cisco 48 port switches any more. You buy 1 swtich capable of running 48 vlans. more than that, you now buy a vitual switch in the back of vmware...that creates virtual adaptors, so one real network interface card can make a given real server be a partipant in n virtual io fabrics. Now, think of ACS the same way. There are times to be real, times to be virtual, times to use roles.

Nothing on the face of it worries me about having 100 namespaces, per say. There is a management API to make them, and you make them like any other object. the API is just a factory object, for making a io/trust fabric, to spec. You can a 1000 of them, if you want.

virtual trust switching (aka ACS ) - a shift in thinking!

Answer 6

There are truly a lot of APPS coming up in the pipeline and these will reach that number in the next 1 odd year.

When we create these many namespaces, we run into process issues.

• Start worrying about how naming conventions for these must be,
• start looking at how these ACS namespace instances will be managed,
• who is going to be given access for these namespaces, ensuring timely termination of these access rights, especially since we are still looking at live Ids for logging and configuring the ACS instances.

I think this list goes on and on, and in my view will very quickly turn into a mess. That is why I need a better solution.

It will be great if I can get a view on how to implement the solution which Oren was pointing out. Since I was under the impression that HRD is only about IDP URLs and not RP URLs.

---

Thanks and Regards, Kanduri

Answer 7

ACS will evolve further, I have little doubt. It took the core leap of "STS" and made it virtualized (so we can all easily have one, called a namespace for now). The very notion of STS was better than the old "hosted IDP/SP" construct at a semantic level, becuase now you can have chains of STS as a designer, each one tune up a little for expressing a custom switch path, with different kinds of processing on each hop. So now you can actually conveive of a mesh (allowing fo great generality), but overaly a specific path concept so particualr signals route the way you want them to go. Obviously, as a designer of paths (vs the arcitect of a mesh with the right overall reach), you tune the path selector - much like you would design a dialplan for a phone system, or a routing network if you are running an ISP.

You are probaby of a mindset that you want 1 namespace, and are going to leverage n RP entities within it. So, lets work with that. As you know RP entities are distinguished by URL (and may be URN, I dont recall well).

In ws-fedp itself, the app (an on-premise IIS server, an azure-hosted webrole, or an Office365 sharepoint site, or ...CRM site, or ... probably) does have the ability to leverage the "ws-reply" endpoint (creating 1 of several possible endpoint to which to send the ACS-generated assertion). The app itself can thus be "tuning up" use of an upstream STS, making it return its result to one of several endpoints (that the app distinguishes, for app-specific switching purposes ).

The STS in Azure doesnt support this feature of ws-fedp (for security reasons). However think. Now have a CHAIN of SP-STS (of which the Azure STS in SP role is the first, and your own is the second - most closest to your app array). Your 100 apps could be talking to YOUR 1 SP-STS (using 100 ws-reply fields), and using the whr vector to have said SP-STS act as a proxy-STS, relaying the request for an IDP assertion to the SP-STS in Azure namesapce X (which then talks to IDP, per the nature of whr). IN this 3 legged chain, the seuqence comes back down the same set of handoffs on the response legs , landing on the PER APP ws-replied' indicated endpoint (in your app land). Your own Sp-STS can thus pretend to be several RPs (in the view of the ACS SP-STS), and thus invoke the particular per-RP/IDP configuration in Azure STS.

This may be your best bet, with the mindset that you have. Dont be frigtened to run your own SP-STS! which "adds" value to the Azure Sp-STS, and then use whr and your own STS to to control the per-RP trust-fabric(s) by that own-STS acting as virutal RPs fronting the app guards (which may or may not further switch on role-claims, or the original-Issuer property of a role claim)

its all just a virtual io switch. its all depends on how you architect it, as to how it behaves and scales. You use each features for  what it good at.

Good luck!

Answer 8

When you say,"You are probably of the mindset..." I am not sure what  you intend to convey there. Do you think it is wrong.

The security reasons you are pointing out for ACS not supporting, I don't think I quite agree but I think that must be a different conversation.

Whatever chaining I choose to use, unless I can make ACS pass on the realm field I seek, I don't think the solution works.

And if I have to use my own STS for managing the trust fabric, I definitely don't need ACS.

So the question remains, How can I get this to work and ensure that as an input to my STS, I can pass on wtrealm attribute to be the RP realm.

---

Thanks and Regards, Kanduri

Answer 9

You are being overly sensitive about wording in written form (a bane of the internet). There is nothing wrong with any one of 10  or rather n different ways of leveraging ACS. There is no "correct way". This is not an academic exam (which trains the mind overly for correctness, particularly in US schools). This is Windows! If it works and somebody is still using it in 3 months time, it's right.

The value of Azure STS (to me, only) when playing in a chain of SP-STS is that it is the bridge to the IDPs (and one has remoted at LEAST that part of the trust fabric out from the App, or the local app-fabric built into vmware, or any other on-premise trust fabric). This particular interprretation has limited applicability (and not all operating worlds want it). If you look carefully, perhaps note how Azure in its SP-STS role has a much more limited claims transformation engine than other more-local SP-STS (and proxying STSs) impelemntation concepts that can do most if not all that Azure ACS does - such as ADFS (or the one you build from the WIF libraries, as we did). Things "bundle" into several families and their operational concepts (with one or other system element's control point "adding value"). Some folks find ADFS a better middleware than ACS. (We found ourself building both our own multi-tenant IDP framework and RP framework, using ACS mostly for its gateway function to "social identities" and a great means of doing home-realm selector UIs, for n different IDP/RP mutual-recognition graphs)

In the "enterprise" model of Windows, one does thing one way (and Azure STS has a quite limited role, in its passive protocol role). In handling social identities in the latest build of ASP Pages (that come with code libs/interceptors that can talk directly to IDPs), perhaps Azure STS has NO role (since one wants now a tight binding of app to IDP). In our world, we use Azure STS MOSTLY for its home realm selector (or rather its JSON feed of the data set, for our local UI rendering of the IDPs for different RP entities in each or OUR tenants' namespaces).

Anyways, hopefully someone else can suggest a specific technical solution, to the requirements as given. The requirements are neither right nor wrong. They are what you want. Hopefully, ACS v2 can be tuned up for what are are.

Trust is fun - as ever - since everyone has a different mental model (and typically its quite an emotive issue). I like ACS as an initiative becuase the product team totally gets that (and thus allow n different folks to apply it n different ways, since it can be "extended"). If it was a dogmatic fabric (more like Google Apps), I probably would reject it totally. Trust is all about the tone, even when you are in the business of running a trust fabric (like  ACS) out of which others go off and deliver their own trust models, given some offloading to ACS of common processing of bits, bytes, keys, endpoints etc.

Answer 10

Hi Oren,

 Rules definitely don't help me here as the data has to come from the IDP.

I thought the HRD only speaks about the IDP URLs. What I need is the RP URL in the wtrealm.

---

Thanks and Regards, Kanduri

The RP can consume the HRD feed and add whatever information it wants. So the HRD feed URL for IDP1 is http://idp1.com/?wa=wsignin1.0&wtrealm=acs.com&...

The RP can modify this value, so that it is http://idp1.com/?wa=wsignin1.0&wtrealm=acs.com...&myCustomRealmParameter=rp.com

Now the IdP knows what it needs to know: who the RP is. I'm not sure this is the cleanest federation model, but I don't see why it doesn't solve your problem.

Alternately, you could modify the wtrealm value directly, however if you do this the audience of the token issued to ACS must still be the correct one or ACS will fail.

Answer 11

out of interest, does ACS pass up to the IDP any wctx supplied by the RP app? We know from disclosures that ACS's request processing endpoint accepts the inbound wctx.

In terms of the model , an RP's URI by default will be hidden from the IDP - as is required But, there is no reason why an RP app should be not undermine that particular security feature - by revealing itself in the wctx.

Answer 12

out of interest, does ACS pass up to the IDP any wctx supplied by the RP app? We know from disclosures that ACS's request processing endpoint accepts the inbound wctx.

In terms of the model , an RP's URI by default will be hidden from the IDP - as is required But, there is no reason why an RP app should be not undermine that particular security feature - by revealing itself in the wctx.

A few minutes of experimentation in Fiddler will show that the wctx that ACS sends to the IdP contains an encoded version of the RP's wctx, along with the RP's realm and reply addresses. However, this should not be relied on as this behavior is undocumented and could change at any time. For example, ACS may choose to encode these values differently, or use a cookie to store them, in which case an IdP relying on this behavior would break.

Answer 13

I'll assume the original question has now been answered, as well as anyone can.

But it does lead to another, highly related topic.

Ive had an expert take a php core library for digsigs and xmlenc and build a unit test package for verifying ws-fedp responses - signed, and then encrypted signed-tokens. This update stuff from the PRP era of ws-fedp, to interworking with a classical WIF IDP (or ACS). I am then responsible for build a handler, leveraging those security priitives. Does my SP-side handle the same semantic as the standard WIF interceptor built into ASP.NET and IIS pipelines now, I then asked myself?

One thing WIF (in its ws-fedp IDP incarnation) does  that a WIF in a SAML2 IDP incarnation does NOT do is include in the signed response/assertion the wctx supplied on the request. (its also present on the POSTed response.)

Now, I come from the security design school that said: if a field is in a signed control message, its there for a purpose. And, as it stands, Im not applying whatever the purpose define the need to bear it within the signed datum.

Now, wctx is supposed to be opaque (and have value only to the original SP). BUt, it evidently has internal structure (id=x, rm=0... passive..).

To interworking as an SP with ACS v2 CORRECTLY (in my php implementation of the SP handlers for responses/assertions), should one be handling wctx in any ACS-specific way, for  the signed version or the POSTed version?

Its prefectly fine for folks to say: only use Windows SP libraries when working with ACS (if you want the full feature set). Only then do you get what ACS was intended to deliver (vs some other IDP concept).

This is all relevant to me because I view the production of a php plugin for token handling (for use in joomla etc) to be a stopgap, pending joomla on IIS having a plugin that delegates to the IIS/WIF pipeline token handling - allowing me to do what I really want (just handle claims...). In that world, I dont really care what wctx does or does not do... But for now, I want to be reasonably complying...