How can an SP send extra information to the IdP

[Nate Klingenstein]

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/527885e7/attachment-0001.html>