Single SP, multiple applications

Steve Teti steti at boardeffect.com
Fri Feb 5 10:21:44 EST 2016


On 2/5/16, 9:26 AM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:



>>But it doesn't solve a couple of issues:
>
>- authorization / limiting of trust
>- endpoint management
>
>The former issue is simply that using one source of metadata at the top level, which is something the SP was meant to do, allows for any IdP to deliver an assertion to any ACS endpoint. That is, you have to be able to separate limiting trust from limiting access. The way we do that in higher ed is by using explicitly scoped, global identfiers for users that don't collide. That breaks down in a lot of simple B2B silos because companies tend to use simple identifiers like an employee ID, which aren't globally unique. So you typically end up needing application controls to limit the IdPs a silo will accept a user from.

Thanks very much Scott, that makes sense. I felt like I was missing something in my model and that explains it. It looks like the best option then will be to set up separate entityIDs. I saw that other providers in the InCommon federation were doing that but I was hoping I could outsmart the system :).

-- 
Steve Teti

>


More information about the users mailing list