Ang: Re: Unsoclicited SSO questions

[Peter Schober]

* Johan Romin <johan.romin at egbs.se> [2015-05-28 16:45]:
> <font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif"
> size="2"><div dir="ltr">I'll try again and hope the message doesn't
> get badly formatted again.<br></div>

<div

*Sigh*

> dir="ltr"> </div>

<div dir="ltr">That much I understand,
> still the service provider 
doesn't want to change their
> implementation as they see this as a 
neccesary
> feature.

There is no "feature" here, anywhere, of course.

> <div dir="ltr">I've tried to alter the metadata on
> our end not to 
require a signed authn request and that just passes
> our end but then 
halts on the service provider end that then
> cannot validate our message.

That's likely the real issue here, as the SP cannot request something
from your side that by definition can only come from themselfs.

> div dir="ltr">Could this be managed by some kind of initation
> through a
 local service provider that I setup on the idp that
> creates the signeds
 authn request which in turn gets forwarded to
> the unsolicited sso 
servlet?

No, because

0. None of this makes any sense (semantically and technically), and
contrary to what you state you don't seem to fully realize this yet.

1. The purpose of signing a SAML2 authentication request is to give
the IDP (as reciever of that request) a chance to validate the content
of the request, by evaluating the signature on the request, and
by checking what entityID the IDP has the used key on record for.
If your SP (i.e., any SP or /anything/ that is not the actual SP
entity) were able to sign a request that would satisfy your IDP's
signature validation your SP would need to have access to the actual
SP's private key. Which of course it should never have.
  While you could manipulate the metadata you have on record for the
actual SP to give it a key of your replacement SP, in order to
validate /your SP's/ authentication request, that does not make any
sense, of course, as it would be functionally equivalent with NOT
doing any of this.

2. With IDP-initated SSO there is no SAML authentication request to
the IDP (hence the name "IDP-initated" or "unsolicited"). Of course
/something/ needs to trigger the IDP's behaviour, so IDP-initiated
just replaces a standard (SAML2.0 core) request to the IDP with a
non-standard, proprietary request (implementation specific, here for
the Shibboleth IDP).

So by doing what you suggest (which makes no sense security-wise or
other) you'd not be using IDP-initiated SSO, and you'd not be
validating that SP's authentication requests.
-peter