Extending the IdP to release a list of all permitted users for a SP.

[Cantor, Scott]

On 4/11/15, 12:02 PM, "Phil Lello" <phil at dunlop-lello.uk> wrote:
>
>I'm relatively new to Shibboleth, and my interest was originally sparked by integration issues between a SP and IdP controlled by the same university.

Something you should bear in mind is that what you're describing is in general *only* applicable to that case, and so that limits the generality and the interest in even attempting to solve the problem you're talking about. Once you go beyond a single IdP, applications that try and load what I like to call "the universe" no longer work well. It's an approach that is designed around an LDAP view of the world, namely that there's a repository in the sky where all data lives. That doesn't scale well to a federated scenario.

>I'm wondering if it would make sense to add an extension to the IdP that allowed a SP to request that an IdP return attributes for all users that the IdP wants to be able to use a given SP. I tried searching the archives, but either my search terms were bad, or this topic hasn't come up before.

The IdP in general doesn't know what that means. It doesn't know what the data it's supplying means to applications, and it doesn't specifically understand that something is a group membership or an entitlement, or just a piece of data. So it doesn't know "all the users that the IdP wants to be able to use a given SP".

It would have to be configured to know this in some undefined way.

Historically, the IdP is both SAML-focused, and focused on making assertions about users. None of the additional protocols it supports have this feature, and we've never done anything around non-user assertions.

This is viewed as more of a provisioning problem and it's assumed that applications that demand wholesale provisioning of users have some way to do that, and to date there are no well adopted standards for that sort of thing. In addition, I think it's, again, a naive way to go about application design that only works well with a single source of users or permissions. This is how most apps see the world, but the federated model is a different one. In that model, you don't get to ask this question because the answer changes, and spans too many source systems to efficiently answer.

Of course, very, very few apps are actually federated, and this is one reason why, it's too big a change.

>On the face of it, this seems to be desirable, since the IdP already takes care of combining and filtering attributes, possibly from multiple sources, and duplicating this process elsewhere is more maintenance.

Not everybody uses the IdP that way. Often that's already done by the IDM system and it's the IDM system that would already be able to answer this question.

>The generic use case is to allow application permissions on a SP to be set up before an IdP user interacts with it for the first time.

I know. We don't have a way of solving that problem for federated systems, and that's the main reason there's nothing in Shibboleth to address it.

>Has this been discussed before? Is it desirable, or are there good reasons why this shouldn't be an option for a relying party?

I think applications need to stop asking that question, but I don't know how to get them to stop asking it.

-- Scott