IDP-initiaded SSO or IdPUnsolicitedSSO

[Peter Schober]

* Jehan Procaccia <Jehan.Procaccia at it-sudparis.eu> [2013-10-16 12:36]:
> >What does the metadata for that SP look like?
> >(You do have metadata for that SP on record, right?)
>
> As they don't run a shibboleth SP (nor a simplesamlphp or whatever
> else ..) they didn't provide me any metadata :-(
> So I "figured out" some myself for them !
> I took some as a template from a traditional 2.5 shib SP and changed
> entidyID , SSL certificate (taken from their https site), and URL in
> bindings reflecting their site name
> you can have a look a it at
> http://shibidp1.int-evry.fr/metadata/fed-sp-ext.xml
> it is the first entityID="https://test.travel.com/travelsite/externalauthenticateimt.jsp"
> I must admit that it is challenging to figure out metadata for
> someone else SP , and I might have guess wrong .

Remove SAML2 from protocolSupportEnumeration, remove all endpoints
that have a Binding mentioning SAML2.0 (ArtifactResolutionService,
SingleLogoutService, AssertionConsumerService), remove any and all
Extension and their child elements, remove all EncryptionMethod
elements. So that it basically looks more something like this:

http://pastebin.com/TVbZjrSu

The ACS URLs in there I made up (guessing it might be the SP's
entityID, as travel.com won't be running the Shibboleth SP software
and the ACS URLs you had are guaranteed to be wrong then). See below
for comments on that.

> here's their workflow specifications (which I deducted to be a
> IDP-initiaded workflow)
> 
> 1 .The user authenticates to the Identity Provider.
> 2. The user requests access to the site Travel Enterprise by
> clicking on a link on the intranet

These two will be one step for your Shib IdP.

> 3 . The Identity provider builds the SAML authentication message
> incorporating the unique identifier shared by Travel and the
> Identity Provider of the customer
> 4 . Travel servers identify the user

There's a step missing between 3 and 4: The IdP sends the data to the
SP at a specific URL meant for processing incoming SAML responses.
You'd need to ask the SP about this URL (and ideally what Binding it
supports there, though you can guess and just try all defined ones, if
you like doing the SP's work).

> If their SP receives that kind of response, then our user should
> access their site.
> If that workflow is compatible with shibboleth, then how can I
> create correct Metadata to feed my IDP with to make it work !?

Receive it /where/?

> >If so does it claim SAML2 support e.g. in the
> >SPSSODescriptor/@protocolSupportEnumeration and
> >AssertionConsumerService/@Binding attributes?
>
> No, according to their SAML reponse massage sample, it supports only
> SAML 1.1

I was referring to your copy of their metadata, and indeed your copy
claimed that the SP supported SAML2.0.

> >>then is there a SAML 1.x IDP Unsolicited/SSO config sample ?
> >I would guess having correct metadata for that SP alone would suffice.
> yes, again, how to create them if they don't provide me metadata for
> their SP  ?

You make it up yourself, taking into account the SP's limitations and
supported protocols and bindings. So you need the same info from the
SP that goesinto SAML metadata: keys (maybe not even those), protocol
endpoints, supported Bindings.
-peter