Attribute Query and bindings

Forum topic: Submitted by Misterburns on Wed, 2009-06-10 10:03. Last updated on Wed, 2009-06-10 13:40.

Hi,

i want to setup an idp which delivers attributes for a subject. So the obvious way would be to implement the 'Assertion Query and Request Protocol'. If i understand the saml-core-2.0-os right this has to be done with the SAML-SOAP-Binding. But i really wish this could be done with the redirect binding which is much easier to integrate into arbitrary service providers.

So here are the questions:

- am i right that the "Assertion Query and Request Protocol" MUST use the SAML SOAP Binding?

- maybe i could create a new profile for this use-case, but is defining a new profile a good way to circumvent this?

Regards

Jens

Login to post comments
12715 reads

Using SAML

Thanks for all your replies

I needed an asynchronous protocol since the idp has to start an applet to read data from an id-card. But i can use an AuthnRequest and put those Attributes as Assertions in the response.

Regards

Jens

I would agree that the Profile for Assertion Query/Request indicates using a synchronous binding. I've only seen SOAP implementations for AttributeQuery, and there might be limitations if your partner is using a Vendor solution.

The SOAP binding can be slightly more effort if firewall rules need to be opened to allow a SAML service server internet access. Browser-oriented bindings that are usually open per default. However, it can be better with SOAP if you wouldn't want the Attribute data exposed through the browser and/or if you can rely on session/transport layer mechanisms for securing the message rather than XML signatures and encryption.

Something that might be an issue in processing - the nice part of SOAP connection is that you might be able to avoid complications of saving state in the middle of processing some other HTTP request (e.g. Authn Assertion)

Perhaps you could put the Attributes in something like the Authn Assertion instead of calling a separate AttributeQuery if you are worried about the binding?

I believe SOAP is required per the spec. Sect 6.3.1 of the Profiles document.

"The SAML requester MUST use a synchronous binding, such as the SOAP binding [SAMLBind], to send
the request directly to the identity provider."

The poster asked if the protocol requires SOAP, and it doesn't. There's a dummy profile in the spec that's there for conformance reasons, and just combines the protocol with a particular binding "pattern" so that people can claim to support it and be tested on it.

However, the front-channel has the problem that the protocol has no support for telling the AA where the response should be sent. It could be done in an extension,or it could be defaulted with metadata, but that's an example of where the protocol assumed a synchronous exchange without actually requiring it.

Nothing in SAML core says anything about that protocol requiring SOAP. I don't see any reason to think it's easier to do it without SOAP, except that front-channel allows for something like user consent much more easily. Since front-channel would require signing, that doesn't translate to "easier to implement" in my book.