Access control of entities in the federation

[eduperottoni]

I don’t understand how the specification deals with access control of federation entities. Nothing is mentioned about this in the text. Suppose I have a complex federation topology with many Relying Parties (RPs) and many OpenID Providers (OPs). The image below illustrates this scenario.

In this use case, all RPs in the federation search on the topology of the federation for all trusted OPs when building the login button for user authentication.

However, RP 3 and OP 3 are exceptions. They are private entities, that must be visible only inside the Intermediate B context. In an educational environment, for example, some universities maintain private services or providers used only by their internal members.

Thus, we have the following requirements:

• When RP 3 searches for OPs to build its login button, it should only discover OP 2 and OP 3 (OPs that belong to Intermediate B).
• When we list RPs available inside the federation, in a possible discovery endpoint, as proposed here, we can't list RP 3.
• When RP 1 searches for OPs to build its authentication button, it can’t list OP 3.

Does this use case make sense? Does this concern fall within the scope of the protocol or should it be addressed at a level above it?
Maybe some text in the specification can help if it makes sense.

Thanks so far!

[cicnavi]

This was also my concern, I think this is duplicate or very related to #135

[peppelinux]

When RP 3 searches for OPs to build its login button, it should only discover OP 2 and OP 3 (OPs that belong to Intermediate B).

solution: it is sufficient using intermediate B as trust anchor

When we list RPs available inside the federation, in a possible discovery endpoint, as proposed #56, we can't list RP 3.

solution: particular cases of exception must be handled in the trust framework and can be implemented using trust marks. RP in white might not have some basic trust marks or, differently, might have some particular trust marks, like https://trust-framwork.b.example.org/openid/rp/leprosy

When RP 1 searches for OPs to build its authentication button, it can’t list OP 3.

as previsouly described for the RP, use the trust marked listing endpoint to filter out particular entities marked in some particular way

alternative solution: use a regexp upon the listing result, based on the white/black list you might find working.

[eduperottoni]

@peppelinux thanks for your explanation, I appreciate it.

I didn't realize we already have the tools to implement this specific use case (I'm not 100% familiar with this spec). Based on your comment, I'll close this issue.

Just one last idea: the new "Implementation Considerations" section could include some paragraph explaining the possibility of the use of these tools (trust maks, listing endpoits, regex upon the listing responses) in order to solve particular federation cases. It's obvious that the specification doesn't need to solve and explain all particular problems, but make it clear that it has tools to solve some problems could help the reader, specially if he/she doesn't have fully mastered the spec. Does this idea make sense?

[Razumain]

@eduperottoni Your use case actually makes a lot of sense and we have thought a lot about use cases like this one in our effort to create a national profile in Sweden.

For this particular use case we have created an optional endpoint supported by the resolver (the discovery endpoint), that will help you do this kind of searches of services within your federation infrastructure: See our draft profile: https://github.com/oidc-sweden/specifications/blob/main/swedish-oidc-fed-profile.md#discovery-endpoint.

To be more explicit. To achieve what you want, I would use Trust Marks as the primary tool to distinguish among the services.
As a first step I would give the regular OP services a Trust Mark the MUST be granted to all "public" OP:s. This Trust Mark is not given to OP3, as it only serve as a private resource.

All general RP:s such as RP1, will include a requirement for the public OP Trust Mark in its discovery request, and hence will not see OP-3. RP-3 will however include the specific Trust Mark given to OP-3 and will se it as a valid option. I think you can accomplish all you want this way.

Note: that you don't absolutely need our "Discovery" endpoint, but if you don't, all RP:s and OP:s have to implement a similar logic themselves.

[zachmann]

I agree with the previous comments. This is a valid use case in hierarchical federations.
One way to solve this is using multiple intermediates one for private entities and one for public entities. While this would work in a very simple scenario, it does not scale well at all. It would make hierarchical federations with multiple layers extremely complex (we already have enough complexity) and a nightmare to manage.

The approach using trust marks is much better. An entity just includes the federation membership trust marks for those (sub-)federations it wants to participate in.

Of course, other entities would need to filter based on those trust marks (or use a discovery service that does so).

[jcmelati]

Although the entities are described as 'private', we should not overlook the fact that relationships in OpenID Federation are bi-lateral and publicly declared.
Being able to establish a valid trust chain between two entities is the root of all trust.
In that sense, in such context and for the entities involved, after building a trust relationship, one could argue that being trusted is better than not being trusted.

Therefore, if all that a Discovery Point is doing is evaluating trust, without using trust marks or evaluating constraints like max_path_length there is no reason why such endpoint would not list OP 3 or RP 3.

If the reason for the OP 3 and RP 3 entities to be part of Intermediate B is to be interoperable with each other, I would say that these internal entities should probably live below a new Internal Intermediate entity, with a constraint "max_path_length": 0, under Intermediate B, so that Internal Intermediate subordinates can establish trust with each other but can't establish trust chains through Internal Intermediate to go higher up in the federation.

[eduperottoni]

Thanks @jcmelati, @zachmann, @Razumain and @peppelinux for your answers, sorry for not replying before. We have the tools to make this use case happen. However, before I close this issue, I want your opinion about the idea I gave in the previous comment:

Just one last idea: the new "Implementation Considerations" section could include some paragraph explaining the possibility of the use of these tools (trust maks, listing endpoits, regex upon the listing responses) in order to solve particular federation cases. It's obvious that the specification doesn't need to solve and explain all particular problems, but make it clear that it has tools to solve some problems could help the reader, specially if he/she doesn't have fully mastered the spec. Does this idea make sense?

[peppelinux]

@eduperottoni I agree about your proposal to get further details within the implementation considerations section

@selfissued @rohe ^

[selfissued]

As a practical matter, two Entities will not be able interact if they cannot see one another's resources. In particular, the Entity Configurations and endpoints needed to interact within a federation must be visible to the Entities using them.

That's not to say that network-level mechanisms such as firewalls, specialized DNS resolvers, etc. might not be used to make some information inaccessible to some parties under some circumstances. Indeed, this is possible. However, how and when to do so is beyond the scope of this specification.

I propose to close this issue on that basis.

If someone is motivated to write specific proposed Implementation Considerations text on this topic, please publish that in a new issue, when ready for review.