AffiliationDescriptor

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

AffiliationDescriptor

Tom Scavo
I searched the wiki for "AffiliationDescriptor" and to my surprise
discovered that IdP V3.4 will have limited support for the
<md:AffiliationDescriptor> role in metadata. That's very cool (and I
am continually blown away by the new feature set in V3.4).

So what happens when we combine an AffiliationDescriptor with a
metadata-driven configuration element? For example:

<!-- disable encryption for the designated RPs -->
<md:EntityDescriptor entityID="..." ...>
  <md:Extensions>
    <mdattr:EntityAttributes>
      <!-- disable encryption -->
      <saml:Attribute
Name="http://shibboleth.net/ns/profiles/encryptAssertions"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue xsi:type="xsd:boolean">false</saml:AttributeValue>
      </saml:Attribute>
    </mdattr:EntityAttributes>
  </md:Extensions>
  <md:AffiliationDescriptor affiliationOwnerID="...">
    <md:AffiliateMember>https://sso.example1.com/sp</md:AffiliateMember>
    <md:AffiliateMember>https://sso.example2.com/sp</md:AffiliateMember>
    <md:AffiliateMember>https://sso.example3.com/sp</md:AffiliateMember>
  </md:AffiliationDescriptor>
</md:EntityDescriptor>

Does this work as expected? What is the best way to load this entity descriptor?

Thanks,

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: AffiliationDescriptor

Cantor, Scott E.
> So what happens when we combine an AffiliationDescriptor with a metadata-
> driven configuration element? For example:

I don't think it works, we don't chase down the affiliations to find their tags as part of existing EntityAttributes logic. It's possible we could do that, but the main purpose was to support the "group" semantic that's already in the API to extend it to affiliation membership.

It would be a fair amount of work, probably involving some refactoring to make tags "appear" virtually on all an affiliation's members.

What would be nice is to be able to attach a tag with a filter based on a condition/predicate that depended on affiliation, which accomplishes the same end result with less or no code changes, but I don't think that works because of the race condition. The metadata's not in place as a service to be able to use it to feed rules for filtering metadata.

My brain isn't really on this side of the project right now so I don't know what all the implications would be.

The main purpose for this was to allow third party signed metadata statements as an alternative to tagging entities. In other words, instead of InCommon tagging the entities that are part of some certification program, that program just issues a signed AffiliationDescriptor entity listing the entities it certifies.

So it's kind of an alternative to tags, not a way of attaching them virtually. The name of the affiliation is the tag in a sense.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: AffiliationDescriptor

Tom Scavo
On Wed, May 23, 2018 at 10:16 AM, Cantor, Scott <[hidden email]> wrote:
>> So what happens when we combine an AffiliationDescriptor with a metadata-
>> driven configuration element?
>
> I don't think it works...
>
> What would be nice is to be able to attach a tag with a filter based on a condition/predicate that depended on affiliation, which accomplishes the same end result with less or no code changes

Yes, that works for me :-) A one-time configuration on a metadata
provider can associate a configuration entity attribute to an entity
that contains an affiliation role. The actual entity list can be
maintained apart from the metadata configuration.

> but I don't think that works because of the race condition. The metadata's not in place as a service to be able to use it to feed rules for filtering metadata.

I don't know what race condition you're referring to. Is there an
existing jira issue that tracks this?

> The main purpose for this was to allow third party signed metadata statements as an alternative to tagging entities.

Yes, I see how that would be useful. The entity containing the
<md:AffiliationDescriptor> role could be signed by the third party.

I asked about this because I'm searching for a scalable "no touch"
method for local management of metadata obtained from remote sources
(such as federations). Affiliation lists can be maintained locally and
provisioned to IdP systems in the same way that local entity metadata
is provisioned into a sourceDirectory of a
LocalDynamicMetadataProvider.

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: AffiliationDescriptor

Cantor, Scott E.
> I don't know what race condition you're referring to. Is there an existing jira
> issue that tracks this?

You're inside the code that constructs the individual components that will make up the MetadataResolverService, as it's loading metadata and running filters for the first time. It therefore by definition cannot take itself as a dependency in order to use itself to look up metadata (in this case an AffiliationDescriptor). It's circular.

We don't currently have any notion of multiple copies of the service, so it isn't possible to define a set of metadata sources that would expose this and then feed that into a another set of metadata sources that would consume the information.

Basically, you can't use the MetadataResolver service as an input component to any of the objects that are built on the inside of the MetadataResolver service itself.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: AffiliationDescriptor

Tom Scavo
On Wed, May 23, 2018 at 10:56 AM, Cantor, Scott <[hidden email]> wrote:
>> I don't know what race condition you're referring to. Is there an existing jira
>> issue that tracks this?
>
> You're inside the code that constructs the individual components that will make up the MetadataResolverService, as it's loading metadata and running filters for the first time. It therefore by definition cannot take itself as a dependency in order to use itself to look up metadata (in this case an AffiliationDescriptor). It's circular.
>
> We don't currently have any notion of multiple copies of the service, so it isn't possible to define a set of metadata sources that would expose this and then feed that into a another set of metadata sources that would consume the information.
>
> Basically, you can't use the MetadataResolver service as an input component to any of the objects that are built on the inside of the MetadataResolver service itself.

Thanks Scott. I captured this issue in jira:
https://issues.shibboleth.net/jira/browse/IDP-1294

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: AffiliationDescriptor

Eric Goodman-2
In reply to this post by Tom Scavo
>> The main purpose for this [AffiliationDescriptor] was to allow third party
>>signed metadata statements as an alternative to tagging entities.

>Yes, I see how that would be useful. The entity containing the
><md:AffiliationDescriptor> role could be signed by the third party.

>I asked about this because I'm searching for a scalable "no touch"
>method for local management of metadata obtained from remote sources
>(such as federations). Affiliation lists can be maintained locally and
>provisioned to IdP systems in the same way that local entity metadata
>is provisioned into a sourceDirectory of a
>LocalDynamicMetadataProvider.

This is something I had looked into as a potential mechanism for my never-dying goal of identifying SPs "approved for UCTrust data release". It's a potentially much more elegant approach than the extremely "touch" method we've batted around (i.e., repackaging federation metadata with our own entity attributes added).

Is it reasonable to use this feature as a direct entity attribute replacement? I.e., publish one AffiliationDescriptor per existing EntityAttribute? Any scaling issues with having too many AffiliationDescriptors, or with descriptors having too many members?

Supporting this would of course rely on all of my client IdPs updating to the most current release of Shib, which likely means I'll have plenty of time to consider the approach, but it does make me consider whether I want to try tilting at that windmill again on the next release.

--- Eric
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: AffiliationDescriptor

Cantor, Scott E.
> Is it reasonable to use this feature as a direct entity attribute replacement? I.e.,
> publish one AffiliationDescriptor per existing EntityAttribute? Any scaling
> issues with having too many AffiliationDescriptors, or with descriptors having
> too many members?

It doesn't work *with* them right now, that was my point, it works instead of them. It's a replacement for the old practice of embedding things inside EntitiesDescriptor groups and then using the group name in the config (explicitly in V3, it has "by group" notions in the syntax for expressing that).

This lets the group definition be fed in separately from the members of the group, so you break apart the limitations on hierarchical groups and where metadata actually comes from.

Given sufficient screwing around with scripting, you can achieve a fair amount of flexibility with it, but without that work, it's still limited to expressing a single set of behaviors in a RelyingPartyOverride matching one or more group names.

Fixing the combinatorial problem of NxN overrides to deal with all the different cases takes a different approach, one of which is the EntityAttributes-driven way of controlling settings.

I think it's reasonable to work out some cases in the code where "attach EntityAttribute to AffiliationDescriptor containing Foo" is equivalent to "attach EntityAttribute to Foo", but right now it's not. And it pretty much physically can't be in certain cases, like trying to use them as predicates inside the metadata configuration, it's just too circular to work.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: AffiliationDescriptor

Tom Scavo
In reply to this post by Eric Goodman-2
On Fri, Jun 1, 2018 at 7:22 PM, Eric Goodman <[hidden email]> wrote:
>
> This is something I had looked into as a potential mechanism for my never-dying goal of identifying SPs "approved for UCTrust data release". It's a potentially much more elegant approach than the extremely "touch" method we've batted around (i.e., repackaging federation metadata with our own entity attributes added).

Eric, would you mind adding your use case to jira?
https://issues.shibboleth.net/jira/browse/IDP-1294

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: AffiliationDescriptor

Tom Scavo
In reply to this post by Cantor, Scott E.
On Fri, Jun 1, 2018 at 7:59 PM, Cantor, Scott <[hidden email]> wrote:
>
> I think it's reasonable to work out some cases in the code where "attach EntityAttribute to AffiliationDescriptor containing Foo" is equivalent to "attach EntityAttribute to Foo"

In Eric's use case, the former is trusted but the latter is not. (The
same is true of the R&S entity attribute, I think.) How is that
handled?

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: AffiliationDescriptor

Cantor, Scott E.
> In Eric's use case, the former is trusted but the latter is not. (The same is true of
> the R&S entity attribute, I think.) How is that handled?

Metadata is truth to this software. They have to be equivalent, so if you don't want something to be true, you have to keep it out of the metadata or remove it.

I think it's reasonable to expect that an attribute of an affiliation applies transitively to its members. I wasn't saying I didn't think that made sense, just saying that isn't implicit in the code at the moment and in certain cases it's not possible to detect that it's true.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: AffiliationDescriptor

Eric Goodman-2
In reply to this post by Tom Scavo
>> This is something I had looked into as a potential mechanism for my never-dying goal of identifying SPs "approved for UCTrust data release". It's a potentially much more elegant approach than the extremely "touch" method we've batted around (i.e., repackaging federation metadata with our own entity attributes added).

>Eric, would you mind adding your use case to jira?
https://issues.shibboleth.net/jira/browse/IDP-1294

Vacation delay. I added a brief summary just now. Feel free to edit or ask me to edit as needed.

--- Eric
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: AffiliationDescriptor

Eric Goodman-2
In reply to this post by Cantor, Scott E.
>> Is it reasonable to use this feature as a direct entity attribute replacement? I.e.,
>> publish one AffiliationDescriptor per existing EntityAttribute? Any scaling
>> issues with having too many AffiliationDescriptors, or with descriptors having
>> too many members?

>It doesn't work *with* them right now, that was my point, it works instead of them.
>It's a replacement for the old practice of embedding things inside EntitiesDescriptor
>groups and then using the group name in the config (explicitly in V3, it has "by group"
>notions in the syntax for expressing that).

I had to come back and re-read this after letting it sit. I think I understand, and I was proposing replacing (hypothetical) EntityAttributes with AffiliationDescriptors. I was asking if there were any significant limitations on using AffiliationDescriptors this way if they get large. (Presuming SIRTFI is a target use case, I'm guessing not.)


So I think I'm talking about the "typical" use case, that this is what's supposed to be done, and that I wouldn't hit the race condition described in Tom's JIRA issue (https://issues.shibboleth.net/jira/browse/IDP-1294). Does this (example below) seem correct?


I'm imagining UCOP (or some UC entity) publishes an AffiliationDescriptor like this in its metadata (in InCommon or a separate aggregate), saying that it's okay to release an employee ID to a list of SPs:

<md:EntityDescriptor entityID="https://UCEntityID">
   ....
  <md:AffiliationDescriptor affiliationOwnerID="https://uctrustrelease.ucop.edu/HypotheticalUCEmployeeID">
    <md:AffiliateMember>https://sso.example1.com/sp</md:AffiliateMember>
    <md:AffiliateMember>https://sso.example2.com/sp</md:AffiliateMember>
    <md:AffiliateMember>https://sso.example3.com/sp</md:AffiliateMember>
  </md:AffiliationDescriptor>
</md:EntityDescriptor>


And the various UC IdPs would do something like this in their configurations:

<AttributeFilterPolicy id="ReleaseEmployeeIDforUCTrustAuthorizedSPs">
   <PolicyRequirementRule  xsi:type="InEntityGroup" groupID=" https://uctrustrelease.ucop.edu/HypotheticalUCEmployeeID"/>
 
  <AttributeRule attributeID="HypotheticalUCEmployeeID">  
    <PermitValueRule xsi:type="basic:ANY"/>
  </AttributeRule>
</AttributeFilterPolicy>


(My IdP configuration experience is 6 years out of date, so apologies for any glaring errors)



I'm still confused around how (or if) the AffiliationDescriptor's groupID is bound to https://UCEntityID EntityDescriptor in the PolicyRequirementRule, but I think that is confusion around how AffiliationDescriptors in general and not anything specific to this thread or Tom's JIRA issue.

--- Eric



--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: AffiliationDescriptor

Tom Scavo
On Tue, Jun 19, 2018 at 3:21 PM, Eric Goodman <[hidden email]> wrote:
>
> I'm imagining UCOP (or some UC entity) publishes an AffiliationDescriptor like this in its metadata (in InCommon or a separate aggregate)...

Note that an aggregate is not strictly necessary. The
AffiliationDescriptor could be distributed as a single entity.

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: AffiliationDescriptor

Cantor, Scott E.
In reply to this post by Eric Goodman-2
> I had to come back and re-read this after letting it sit. I think I understand, and I
> was proposing replacing (hypothetical) EntityAttributes with
> AffiliationDescriptors. I was asking if there were any significant limitations on
> using AffiliationDescriptors this way if they get large. (Presuming SIRTFI is a
> target use case, I'm guessing not.)

Just the usual ones I guess, there might be some scaling issues in the code. I don't think it indexes any of this, it's pretty brute force. It wan't meant for large groups any more than anything handles that well. That's an EntityAttribute use case, certainly.

> So I think I'm talking about the "typical" use case, that this is what's supposed
> to be done, and that I wouldn't hit the race condition described in Tom's JIRA
> issue (https://issues.shibboleth.net/jira/browse/IDP-1294). Does this (example
> below) seem correct?

The feature is a replacement for EntitiesDescriptor groups moreso than EntityAttribute tagging, but if the set of SPs is smallish, it's fine as long as you don't intend to apply a rule in a metadata filter to do something based on the membership of that SP in an AffiliationDescriptor. That's the race...you can't process/filter/add to metadata using criteria based on another piece of metadata. I doubt that will ever be possible, but it would take a lot of work if it is, and probaby would look somewhat like what the SP software does in places, it actually supports sort of "nested" MetadataProviders that get processed and consumed by other components. It's a mess in most cases and nobody has ever done it.

Your attribute release example is the kind of case that works ok.

> I'm still confused around how (or if) the AffiliationDescriptor's groupID is bound
> to https://UCEntityID EntityDescriptor in the PolicyRequirementRule, but I
> think that is confusion around how AffiliationDescriptors in general and not
> anything specific to this thread or Tom's JIRA issue.

Yes, it's a bit odd. The entityID of the EntityDescriptor containing the AffiliationDescriptor is the name to which you attach policy based on the affiliation. It's a bit wacky, but it's because the top level object was EntityDescriptor and the schema didn't make AffiliationDescriptor an alternative top level thing with its own ID.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]