Authentication with SAML2 assertion only

[Marek Denis]

Hello,

Continuing this thread. I am currently in the middle of writing a
piece of software for creating a SAML assertion to be consumed by a
SP. Providing I already know what is the SP endpint
(sp.com/Shibboleth.sso/SAML2/POST) I shall use for sending my saml
assertion do I actually need any other information from the SP
Metadata? Why would SP expose it's public key? Is it used for
validating that SAML request was issued and unchanged somewhere
between SP and IDP?
Thanks.

Not sure you can have unsolicited responses with ECP, from the top of
my head. For one I think the IDP would need an endpoint to do
IDP-initiated ECP, which probably no IDP has.

Strictly speaking, true. So I should amend my answer to say that it
requires spoofing a request from an SP, and yes, that can break some SP
implementations. Doesn't affect mine of course.

Ah, right. So you'd simply do that in your ECP client too.
(Ignoring for the moment what the OP's percieved problem with
SP-initiated is, or how an agent controlling an ECP client would even
know the difference.)
-peter
--

[Tom Scavo]

Post by Marek Denis
Continuing this thread. I am currently in the middle of writing a
piece of software for creating a SAML assertion to be consumed by a
SP.

Given that there are numerous SAML IdP implementations to choose from,
that course of action is not advised.

Post by Marek Denis
Providing I already know what is the SP endpint
(sp.com/Shibboleth.sso/SAML2/POST) I shall use for sending my saml
assertion do I actually need any other information from the SP
Metadata? Why would SP expose it's public key? Is it used for
validating that SAML request was issued and unchanged somewhere
between SP and IDP?

Your questions have nothing to do with Shibboleth and are further
indication that you're probably going about this the wrong way. Why
not use one of the thoroughly tested SAML IdP implementations?

Tom

[Marek Denis]

Post by Tom Scavo

Post by Marek Denis
Continuing this thread. I am currently in the middle of writing a
piece of software for creating a SAML assertion to be consumed by a
SP.

Given that there are numerous SAML IdP implementations to choose from,
that course of action is not advised.

Post by Marek Denis
Providing I already know what is the SP endpint
(sp.com/Shibboleth.sso/SAML2/POST) I shall use for sending my saml
assertion do I actually need any other information from the SP
Metadata? Why would SP expose it's public key? Is it used for
validating that SAML request was issued and unchanged somewhere
between SP and IDP?

Your questions have nothing to do with Shibboleth and are further
indication that you're probably going about this the wrong way. Why
not use one of the thoroughly tested SAML IdP implementations?

Long story short:
http://specs.openstack.org/openstack/keystone-specs/specs/juno/keystone-to-keystone-federation.html
where cloud users want to burst into other clouds. Local Identiy
Service would simply act as a SAML Identity Provider and issue a SAML
Assertion basing on a OpenStack Token, something completely unrelated
to the SAML world.

[Tom Scavo]

Post by Marek Denis
http://specs.openstack.org/openstack/keystone-specs/specs/juno/keystone-to-keystone-federation.html
where cloud users want to burst into other clouds.

I don't know what bursting is but a quick read of the above document
suggests we're probably not talking about SAML here (let alone
Shibboleth). SAML Web Browser SSO assumes the presence of a user who
transmits SAML messages between IdP and SP via the browser. SPs do not
transmit SAML messages to other SPs (as indicated in Figure 2) unless
you're thinking that the ACME thingy in the middle is an IdP Proxy
(with both SP and IdP capabilities). In that case, you should be
looking at simpleSAMLphp, which has good IdP Proxy capability out of
the box.

Tom

[Cantor, Scott]

Post by Tom Scavo
I don't know what bursting is but a quick read of the above document
suggests we're probably not talking about SAML here (let alone
Shibboleth). SAML Web Browser SSO assumes the presence of a user who
transmits SAML messages between IdP and SP via the browser. SPs do not
transmit SAML messages to other SPs (as indicated in Figure 2) unless
you're thinking that the ACME thingy in the middle is an IdP Proxy
(with both SP and IdP capabilities).

Or it's a delegation problem.

-- Scott

[Cantor, Scott]

Post by Marek Denis
Continuing this thread. I am currently in the middle of writing a
piece of software for creating a SAML assertion to be consumed by a
SP. Providing I already know what is the SP endpint
(sp.com/Shibboleth.sso/SAML2/POST) I shall use for sending my saml
assertion do I actually need any other information from the SP
Metadata?

That depends how serious you are about implementing SAML.

Post by Marek Denis
Why would SP expose it's public key? Is it used for
validating that SAML request was issued and unchanged somewhere
between SP and IDP?

No, it's for encryption, and for authenticating signatures or TLS
connections made by the SP as part of other bindings and profiles.

As Tom noted, if you have SAML questions, they should go to saml-dev at
OASIS.

-- Scott