[Federation] Devise mechanism for policy metadata to enforce entity type(s) of subordinates

[Vladimir Dzhuvinov]

Discussed in person with Roland Hedberg at the OAuth sec workshop in Trondheim:

At present we have a mechanism to enforce policies regarding metadata fields for OPs and RPs (and other types) in a federation trust chain, but no way to enforce what types subordinates MAY or MUST have, e.g. a rule like “all subordinates must be OPs”. This came up in a discussion on GAIN.

If the existing metadata policy scheme is not suitable perhaps another method could be invented.

[Giuseppe De Marco]

+1
What would be the implementation proposal to get his feature, do we want to have a special claim inside the metadata_policy object or outside of it?

[Vladimir Dzhuvinov]

Replace entity role with entity type to conform with spec terminology

[Vladimir Dzhuvinov]

Roland came up with a brilliant suggestion that requires no change to the entity statements - take the presence of a metadata policy in a trust chain to mean that an entity type may / must be present.

I will word a concrete suggestion to update the spec and will post it here.

[Vladimir Dzhuvinov]

The proposed addition to the spec:

‌

---

5.2 Leaf Entity Types Policy

In a federation it may be desirable to convey a policy that sets the types of Leaf Entity, as listed in Section 4, that are required or permitted under a Trust Anchor or Intermediate Entity.

For example, a federation may need to convey a policy that only OpenID Providers are permitted under a certain Intermediate Entity, and if a Leaf Entity implements some other Entity type, such as an OpenID Relying Party, it should be deemed non-trusted and its requests, such as OpenID authentication requests, rejected or ignored.

If a federation has a requirement to implement a Leaf Entity type policy, this is conveyed by the presence of a metadata policy for the given type, as specified in Section 5.1. For example, the presence of a metadata policy for an openid_provider can be interpreted as requirement or permission for Leaf Entities to serve as OpenID Providers.

The means by which a federation indicates that a Leaf Entity types policy is in force is outside the scope of this specification.

---

‌

Note, the proposal is not to make this mandatory to apply to all OIDC Federation implementations, hence the last sentence. Software and libraries may choose to activate this entity types policing with a configuration, to be set when a federation agrees to enforce such a policy. If you have other suggestions or ideas around this, please share them.

‌

With this OIDC Federation will have a total of 4 policy tools (all of them essentially optional) that can be combined in a federation:

1. Leaf Entity metadata policy
2. Leaf Entity types policy
3. Constraints
4. Trust marks

‌

‌

[Giuseppe De Marco]

We may consider that a TA or its intermediaries can normate that only the entities listed in the entity statements metadata_policy are allowed for a specified descendant.

This is an implementation aspect of a Federation. We may consider to add some text just to say that metadata_policy CAN be adopted also in this way.

Having said that, the metadata_policy could be also defined in this way

"metadata_policy": {"openid_provider": {}}

‌

[Roland Hedberg]

After discussion with @Giuseppe De Marco and @mbj we think we should do it this way:

Something like:

"federation_entity": {
  "federation_fetch_endpoint":
    "https://example.com/federation_fetch",
  "federation_list_endpoint":
    "https://example.com/federation_list",
  "name": "The example cooperation",
  "homepage_uri": "https://www.example.com",
  “leaf_entity_types_supported”: ['openid_provider','openid_relying_party']
}

‌

[Michael Jones]

@Roland Hedberg to write a PR.

[Vladimir Dzhuvinov]

Thanks for the updates, I can see intensive brainstorming is going on in Trieste :)

I liked the explicit nature of leaf_entity_types_supported and would like to propose something that builds upon it:

The entity statements fall into two categories:

1. Self statement
2. Statement about subordinate

The second category - statement about subordinate - is where enforcing of the permitted entity type(s) should logically happen, because it’s a statement from an authoritative issabout a specific sub . This means the entity type(s) of the subject can be listed exactly. And similarly, the allowed entity types of possible subordinates of the subject.

E.g. to borrow the example from https://openid.net/specs/openid-connect-federation-1_0.html#rfc.appendix.A.2.5

{
  "iss": "https://swamid.se",
  "sub": "https://umu.se",
  "jwks": {...},
  "metadata_policy": {
    "openid_provider": {...}
  },
  "entity_types": [ "intermediate" ], // the subject type(s)
  "subordinate_entity_types_allowed": [ "openid_provider" ] // list of allowed subordinate types
}

Or from https://openid.net/specs/openid-connect-federation-1_0.html#rfc.appendix.A.2.3

{
  "iss": "https://umu.se",
  "sub": "https://op.umu.se",
  "jwks": {...},
  "metadata_policy": {
    "openid_provider": {...}
  },
  "entity_types": ["openid_provider"] // the entity is an OP, no subordinates allowed
}

The entity_types is plural, because the entity statements appear to permit (per current spec) an entity ID to be for example both an OP and RP (Roland - is this correctly intended?) If this mixing / plurality of types of not allowed, this may simplify the spec and implementations somewhat.

https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.4

What are your thoughts on this?

PS: the subordinate_entity_types_allowed can also appear in self-statements of anchors and intermediates.

[Roland Hedberg]

Allowing an entity to publish metadata for more then one entity type is a feature not a bug.

[Vladimir Dzhuvinov]

Allowing an entity to publish metadata for more then one entity type is a feature not a bug.

Okay, so https://something.example.com can be both an RP and OP at the same. Or an AS and OP. Makes sense :)

[Roland Hedberg]

I would expect the combo OAuth2 client and RP.

[Roland Hedberg]

If we are to place this in the Entity Statement about a subordinate it belongs under constraints .

For example:

"constraints": {
    "max_path_length": 2,
    "subordinate_entity_types_allowed": ["openid_provider"]
},

Note that I’m not say we should go that way only if ..

[Vladimir Dzhuvinov]

it belongs under constraints

Agree, this is in fact the placing of a constraint!

Plus, it will then get to inherit the existing constraint rules:

If a subordinate entity statement contains a constraint specification that is more restrictive than the one in effect, then the more restrictive constraint is in effect from here on.

If a subordinate entity statement contains a constraint specification that is less restrictive than the one in effect, then it MUST be ignored.

https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.5.2

[Vladimir Dzhuvinov]

More thoughts on the entity types constraints:

• If we keep the current default policy, “allow all” is the default one for the subordinates.

• When a policy is specified federations will likely want to be able to specify:

  • intermediate
  • leaf of any type(s)
  • leaf of specific type, e.g. openid_provider

To express these the spec will need to declare syntax and / or identifiers for intermediate and leaf

‌

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/212/leaf-entity-type-constraint