The SAML web site is not longer accepting new posts. Information on this page is preserved for legacy purposes only. For current information on SAML, please see the OASIS Security Services Technical Committee Wiki.

N-tier usage of SAML in the backend

Dear all,

after lots of recherche, I did not find a general, standards based solution for the following problem:

I am implementing SAML for a SOA system, where we would like to use it in addition to Kerberos based delegation model. The problem with Kerberos is that its infrastrucutres are often tied to a specific local environment (like Active Directory).

Let us assume I have two service providers (SP1, SP2). SP2 is behind the scenes and should act on behalf of the client. The connection to SP2 is not performed from the user context (via redirection) but via a connection from SP1. So the user context is lost after entering SP1. (This is this backend scenario). Furhter we have a common IdP, which knows and trusts (via metadata) both SPs.

AFAIK is that the SP has to always get the assertion directly from the IdP - out of security reasons, which would not pose a problem. What I do not have is the user's context that originally provided the credentials when doing the logon for SP1.

So what I would need is something described in

Furhter I found that the higgins project also provides some extension what they called, in order to get an assertion from an existing assertion?

What is your opinion on that? I really like SAML and would like to use it for something like that. Yet I would like to talk to standardized IdP, so it would be good to have a standard conform way to getting an Assertion of the user in SP2.

I have read that liberty addresses some of this issues but I am a kind of newbie in this area and the liberaty standards are pretty large. Maybe someone is able to point me in the right SAM2 Profile/diection....

Another question: What defines an SP. Can a single SP also be defined by multiple locally known and trusted web services?

Thank you in advance



I can't follow any of what you're trying to describe, but if you're looking for a specification set that does what my delegation paper was describing, for SOAP applications, that's Liberty. That's why I worked on those specs. That paper is just describing in rough terms what the requirements were. ID-WSF meets them.

I'm sorry that the Liberty specs are large, but what you're trying to do is not simple, and much less simple when the solution has to generalize. The Shibboleth wiki includes a detailed discussion of exactly what pieces of ID-WSF are relevant to the basic problem.

Hi Scott,

thank you for your reply. If you are referring to your paper as the "constrained delegation profile for SAML" yes that is something I would like to achieve. Great to see that this is specified in liberty.

I will go to the Sibboleth wiki and look if I can find the representative profiles.

Maybe you can directly point me to the Wiki page?

Thank you in advance




Given SAML2.0 Core, how would you concretly implement the following scenario with SubjectConfirmation:

  • User logs into web site, which accesses a SOAP service on behalf of user
  • User logs into web site, which accesses a SOAP service on behalf of user, then SOAP service accesses second SOAP service on behalf of user (and so on...)

So I have to make sure that the SAML assertion being a message security layer - can somebody give me a concrete example on this. I am not a security expert.

What is the right/best SubjectConfirmation to use? Has the SOAP service then again have to contact the IdP or simply trusts the IdP's assertion. Has anyone implemented a similar system?

Thank you in advance

SAML alone doesn't define that kind of thing, it requires a whole collection of related profiles, which is what the now defunct delegation paper you're trying to follow was attempting to explain

Liberty ID-WSF defines how to do all of those things in a lot of different ways.

Subject confirmation is a tiny, if important, piece of this use case. Liberty's security mechanisms for message authentication with SAML define what goes in it. Both bearer and holder of key approaches are possible.

Assertion consumers rarely, if ever, need to go back to the IdP to validate assertions, that's not the SAML model.

If you're not a security expert, or at least very knowledgeable, that should send up red flags for you. This stuff isn't simple.

I think I know enough about security techniques to implement it (based on existing libraries), yet it would be nice to see at least one concrete way and discuss its pros and cons. What I find difficult about this discussion are phrases like "those things" and "a lot of different ways". I am quite aware of the fact that this is complex but it would help to see one concrete example of how somebody realized it.

Unfortunately I am in the position of having a non simple environment, where the user context is not always availale to me. Yet I think that this infrastructure provides the best means to implement it in terms of Web technology.

As my next steps I will read the ID-WSF SecMech SAML2.0 Profile as well as try to look at ID-WSF implementors like ZXID. Any other advise is greatly appreciated.

Unfortunately your use case isn't presented in enough detail to drill into, and I wouldn't do it here in any case. There are existing mailing lists for these discussions like saml-dev and the openliberty list, and these forums are a poor substitute and impossible for me to keep up with.

If you want to see a concrete example, there's one in the Shibboleth wiki under the MetaSearch topic.

I'm not personally connected with anybody who has successfully implemented any of this in anything but a trivial context. I'm not saying it hasn't been done.

My project is now working on a proposal to implement a bearer-based model for REST services and web sites using the SAML ECP profile and the Liberty SSOS spec that I defined. If that's interesting to you, you can join the shibboleth-dev list to follow that work. Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I