"Central Discovery Service" initiated discovery/login

[Patrick Radtke]

We have an central discovery service, which in certain situations,
wants to initiate the discovery/ login flow for a user without the
user having visited the SP prior to coming to the central discovery
service.

If the SP is Shibboleth there is no issue. The discovery service can
send the user to the "idpdisc:DiscoveryResponse" url from the Metadata
and the SP will start the login flow, and once complete send them to
the configured 'homeUrl'
Example url discovery sends user to:
https://sp.example.com/Shibboleth.sso/Login?entityID=idp.example.org

With SSP, things aren't so simple. DiscoveryResponse url isn't
published in the metadata, and even if it was the regular disco
response url wants an AuthID so it can load state and find the correct
authsource. This means discovery can't be initiated from the central
discovery service
Example:
https://sp.example.com/module.php/saml/sp/discoresp.php?AuthID=_3315c&idpentityid=idp.example.org

I'm looking for ideas, or advice on how to proceed.

Should I create my own discoresp url pattern, like
"https://sp.example.com/module.php/saml/sp/discoresp.php/AUTHSOURCE"
(similar to how saml2-acs.php determines the authsource) and work on
optionally publishing it in the metadata?
That may work for SSP, but obviously wouldn't help me with SPs using
other software.

Is there a better way to approach centrally initiated discovery/login?
Create the AuthnRequest on behalf of the SP?

thanks,

Patrick

[pat...@cirrusidentity.com]

After reading more specs I found the correct term for what I want is "Session Provider Request Initiation Protocol" http://docs.oasis-open.org/security/saml/Post2.0/sstc-request-initiation.html

This is supported by Shibboleth, but not by SSP (https://github.com/simplesamlphp/simplesamlphp/issues/174), and I couldn't tell about support from other SP software vendors.

The spec says to use the RequestInitiator value from the Metadata, rather than DiscoveryResponse that the app had been using - though in the case of Shibboleth they seem to be the same URL.

-Patrick

[Jaime Perez Crespo]

Hi Patrick!

Sorry for the late response, but I had to do some reading before being able to offer you a proper reply...

We’ve had a related issue for quite a long time:

https://github.com/simplesamlphp/simplesamlphp/issues/28

I think we should basically implement the Service Provider Request Initiation Protocol as requested by Tom in #174. My initial thoughts are:

- Use a different, new endpoint for this. “SSPROOT/module.php/saml/sp/ssoinit.php/authsource”? I think it’s perfectly fine to append the auth source name to the URL. That’s what we are doing with the rest of the endpoints in SP metadata, after all.
- Implement the protocol in that endpoint as described by the specification, paying special attention to the target parameter, which we should check as allowed (SimpleSAML\Utils\HTTP::checkURLAllowed($target)) after coming back from authentication. I don’t know if we should show an error if $target is forbidden by configuration or just redirect to the default URL.
- Make sure the SP metadata registers and exposes this endpoint URL as per the specification, maybe having a configuration option to tell whether to publish it or not, similarly to what we have already for other parts of metadata.

We don’t have this in the roadmap, and to be honest, I don’t have any clue on how big an amount of work would it be to implement this (though my impression is that it wouldn’t be too much). Would you be willing to help with the implementation?

> --
> You received this message because you are subscribed to the Google Groups "SimpleSAMLphp" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.
> To post to this group, send email to simple...@googlegroups.com.
> Visit this group at https://groups.google.com/group/simplesamlphp.
> For more options, visit https://groups.google.com/d/optout.

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Patrick Radtke]

Thanks for the pointers Jaime.

Do you think the feature should be enabled by default? or require enabling?

I started adding some preliminary support (so far just enough to
unblock the demo I was working on) to
https://github.com/pradtke/simplesamlphp/tree/174-request-initiation-protocol

I'll work on flushing out the rest to conform to the spec and take a
look at getting it published into the metadata.

-Patrick

and I'll work on

[Jaime Perez Crespo]

Hi Patrick!

On 22 Jul 2016, at 20:23 PM, Patrick Radtke <pat...@cirrusidentity.com> wrote:
> Thanks for the pointers Jaime.
>
> Do you think the feature should be enabled by default? or require enabling?

Well, as long as it works out of the box (meaning, it doesn’t need any additional configuration), I would say it’s ok to have it enabled by default. I don’t see any particular harm, but of course I could be missing something. Maybe Tom Scavo can share his view on this.

> I started adding some preliminary support (so far just enough to
> unblock the demo I was working on) to
> https://github.com/pradtke/simplesamlphp/tree/174-request-initiation-protocol
>
> I'll work on flushing out the rest to conform to the spec and take a
> look at getting it published into the metadata.

That’s great, thanks a lot! Let me know if you need help with anything :-)

[Keith Hazelton]

Patrick,

 

I’m curious to know what use you are thinking of making for the SP Request Initiation Protocol.  Some of us had contemplated using it as part of harmonizing IMSGlobal’s LTI spec and SAML WebSSO.

 

             --Keith Hazelton

--

[Patrick Radtke]

> I’m curious to know what use you are thinking of making for the SP Request
> Initiation Protocol. Some of us had contemplated using it as part of
> harmonizing IMSGlobal’s LTI spec and SAML WebSSO.

We are using it as part of a SaaS invitation/guest management service.
After a user has been invited and completed invitation process we want
to send the user to the SP and indicate to the SP what IdP to use.
We've already determined the correct IdP as part of the invite flow,
and don't want the user to have to do double discovery.

-Patrick