How can an SP send extra information to the IdP

Dave Perry Dave.Perry at hull-college.ac.uk
Fri Jan 8 09:09:17 EST 2016


The PingOne approach, I think Marvin found on investigation, was that it returned a unique ID for that tenant of a 3rd party SP. If only in that case.

Here is the full thread for context and more details:
http://shibboleth.1660669.n2.nabble.com/PingOne-SP-td7621601.html

Dave

_________________________________________________
Dave Perry
eLearning Technologist, Hull College Group

Room L34 - Queens Gardens Library
Wilberforce Drive, Queen's Gardens, Hull, HU1 3DG
Extension 2230 / Direct Dial 01482 381930

* Need a fast reply? Try elearning at hull-college.ac.uk<mailto:elearning at hull-college.ac.uk> *

From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Nate Klingenstein
Sent: 08 January 2016 13:54
To: users at shibboleth.net
Subject: Re: How can an SP send extra information to the IdP

There are a lot of gateway approaches that allow a number of SP's to be aggregated behind a single quasi-proxy IdP.  Okta, Windows Azure AD Connect, PingOne, etc. are all good examples.

But to my knowledge, in instances where they delegate authentication back to you, they don't relay the ultimate SP to be accessed in the SAML authentication request itself.  There are numerous ways to relay additional information like this in standardsland, but there is no approach of which I know that is adopted in deployment.

So, unless you can make the requests really look like they're coming from different entityID's per Tom's suggestion, you're effectively making a protocol extension or leveraging a part of the specification suite that is not widely implemented.

That doesn't leave you with a lot of great answers.  I guess my ultimate comment would be to invest as much time in this as you think you will need to use it for.  If you want this to be a real feature that is really adopted, I would suggest looking at the options the standards present and proposing something new if there's nothing palatable.

This is the sort of situation where an ounce of design can prevent gallons of pain later, but also where a quick, expeditious hack(like what you did with IdPv2) may be good enough.
On 01/08/2016 06:26 AM, Dave Perry wrote:
There was a service mentioned recently which did something like this (an SP that acted as a proxy). I can't remember the name of it, and have deleted the emails. PingOne maybe?

Dave

_________________________________________________
Dave Perry
eLearning Technologist, Hull College Group

Room L34 - Queens Gardens Library
Wilberforce Drive, Queen's Gardens, Hull, HU1 3DG
Extension 2230 / Direct Dial 01482 381930

* Need a fast reply? Try elearning at hull-college.ac.uk<mailto:elearning at hull-college.ac.uk> *

From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Bogdan Albei
Sent: 08 January 2016 13:12
To: Shib Users
Subject: Re: How can an SP send extra information to the IdP

That is true, but we are integrating with certain SPs, such as Office 365, for multiple customers.  We need to know, as part of our workflow, on behalf of which customer the authorisation is requested. Identifying by entity id won't work because of the one-to-many relationship between the SP and the customers on behalf of which we integrate with that SP.

On 8 January 2016 at 12:51, Tom Scavo <trscavo at internet2.edu<mailto:trscavo at internet2.edu>> wrote:
On Fri, Jan 8, 2016 at 4:43 AM, Bogdan Albei <bogdan.albei at callsign.com<mailto:bogdan.albei at callsign.com>> wrote:
>
> We are an IdP that integrates with various SPs on behalf of our customers.
> Let's say we have customer A and customer B that both want us to act as an
> IdP and provide authentication for Office 365. The problem is when we
> receive a SAML request from Office 365(the SP). At that point we need to
> know if that request is made on behalf of customer A or customer B. How
> could the SP send that extra information?

The SAML AuthnRequest contains the globally unique entityID of the SP
making the request (or more accurately, the SP wishing a response). So
no "extra information" is needed.

Tom
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>



--
Bogdan Albei
Senior Platform Engineer
Callsign Inc.
[C] bogdan

The Review Newsletter<http://www.hull-college.ac.uk/about-us/stakeholders-newsletter>

This message is sent in confidence for the addressee  only.  It may contain confidential or sensitive  information.  The contents are not to be disclosed  to anyone other than the addressee.  Unauthorised  recipients are requested to preserve this  confidentiality and to advise us of any errors in  transmission.  Any views expressed in this message  are solely the views of the individual and do not  represent the views of the College.  Nothing in this  message should be construed as creating a contract.

Hull College Group owns the email infrastructure, including the contents.

Hull College Group is committed to sustainability, please reflect before printing this email.
________________________________



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160108/d4e0aeaf/attachment.html>


More information about the users mailing list