OpenSAML user discussion

[Brent Putman <>]

On 3/20/2010 12:53 AM, rangeli nepal wrote:

By Client side auth., I was under the impression that SP will provide its cert to IDP ( obviously idp wil provide its ssl credential to SP) before real user is presented with login screen.

But reading  your email, it looks, if we are doing Web browser based SSO profile,we can not do that.

Once SP redirects to IDP, interaction is constrained in between IDP and web browser and Web browser does not have SP cert.

Well, correct, the browser can not do client TLS auth to the IdP using the SP's cert.  When you are doing front-channel, note that the SP and IdP are not communicating directly, at the transport level. There are actually 2 legs of the transport there:  SP to browser and then browser to IdP.  So the SP can't present its cert to the IdP directly, and the vice versa.

If what you are asking is: in front-channel binding, how can the IdP authenticate the SP's SAML protocol message - the answer there is usually that the SP signs the message and the IdP validates.  In addition to the integrity property, the digital signature also conveys authentication of the signer.  So that's usually how an SP authenticates itself to the IdP over a front-channel binding.  That's basically using message-level security (vs. transport level, for example TLS).  The same is also true in the reverse direction - the IdP signs the response and/or assertion it issues, and the SP is able to authenticate the message by validating the signature.


--Brent

 

 

On Fri, Mar 19, 2010 at 11:00 PM, Brent Putman <> wrote:

On 3/19/2010 9:51 PM, rangeli nepal wrote:
> Good Evening Everybody,
>
> I am trying to write a SP which will communicate with an IDP that
> requires client side auth.

What do you mean by "client side auth"?  If the "client" in this case is
a web browser user agent, and you are invoking a front-channel binding
(as implied by the encoders you mention below), for example as a part of
the Web SSO profile, the answer is: you (SP) doesn't handle this.
Authentication of the browser user to the IdP is up to the IdP, and is
out of scope of the SAML spec (at least the Web SSO profile).

If you are talking about communicating with the IdP over the SOAP
binding, and the IdP requires client TLS auth, there is an example of
that here:

https://spaces.internet2.edu/display/OpenSAML/OSTwoUserManJavaSOAPClientExample

> Looking that the classes provided  in opensaml I see clasess like
> HttpRedirectDeflateEncoder or HttpPostEncoder that does most of the
> things.
> They even dispatch the request using sendRedirect or post method.

Those encoders implement the similarly-named front-channel bindings of
SAML. In those use cases, you as the SP are not involved in how the
browser user agent, in the middle of the flow between the IdP and SP, is
authenticated.


--Brent