Contexts and attribute operations

[Cantor, Scott]

On 12/28/13, 12:00 PM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>For the record the extra parameterization consists of:
>	Strings (4): principal, attributeIssuerId,  attributeRequesterId and
>principalAuthenticationMethod
>	Metadata Fragments(4): EntityDescriptors and RoleDescriptor for
>requester and issuer.

The issuer metadata I definitely don't want to keep. Other than backward
compatibility, what's the use case?

>I¹d like to revisit this and ask (and here I probably mean mostly Scott)
>whether we think this is where we want to be.  As I see it we have three
>options:
>
>1)	Leave things as is, but make the navigation a little bit more
>sensible
>2)	Move all the parameterization into the workspace context (which
>already contains some parameters after all)

Well, my suggestion is that the we copy the string fields into the
AttributeResolutionContext explicitly as data and we'll set those in the
profile flow.

I was going to suggest we pull the principal name from the SubjectContext,
but we can't do that if the resolver runs during authentication. I think
any time we bake in assumptions about how something's getting used, we'll
just regret it. Rather than indirecting things through weird lookup
tricks, I suggest we just copy simple data like that around.

For the requester metadata, I suggest we use a lookup strategy for that
because we already have an context type for wrapping that,
SamlMetadataContext. We can insist that that information be supplied using
that kind of context, and then provide a lookup function for how to locate
it, which in the profiles will be from the inbound message context tree.

>3)	Add code to grab this information from the ProfileContext
>[in]directly.  If all the information is always in the ProfileContext,
>that
>might be fine, but I suspect that it isn't and hence I don't like this
>option much since it does tie the resolution code to the precise context
>relationships.

I agree that some things are not always going to be present.

I think the difference with the metadata is that we have a class defined
for how you would access the metadata given the context reference. But the
other string data, we don't have any fixed context type that would supply
them using particular methods. On one context, it might be "getId",
another would be "getEntityId".

-- Scott