RequestedAttributes in SP metada

[Cantor, Scott]

On 12/30/13, 10:30 AM, "Nick Amon" <namon at xceedium.com> wrote:
>
>Thinking it through further, this shouldn't be an issue for us.  We plan
>to internally parse the SP's metadata so that we can determine what
>attributes it is requesting and allowing the administrator of our product
>in the UI to map these requested attributes to attributes stored in our
>product.

Unless you control the SPs, you are not going to get people to give you
that information in the general case. Metadata rarely contains that
information. If you control the metadata, you could of course manually
maintain it, but that defeats the purpose of metadata really.

>  Since the attributes that will be released by the Idp will differ based
>on the SP and the policy configured in our UI (ultimately store in DB
>table), defining them statically in the attribute-resolver.xml file
>doesn't seem to be the right approach to take.

The resolver is not designed to selectively resolve data. It resolves
everything by design. What you're talking about is filtering.

>  I was considering developing my own AtttriubteResolver implementation
>that would read the attributes to be released to the SP from the database
>and then configure the Idp policy to simply release all attributes to the
>SP.  Is this the right approach to take?

No, not really. Just generate the filter policy from the database.

>Also, it appears from your responses and other messages in the dev list,
>that the 3.0 version of the Idp that is being developed may internally
>work differently from the current stable 2.4 version.  When do you plan
>to release this?  I wonder if it makes sense for me to begin my
>development against the 3.0 codebase or the 2.4 codebase.

That depends on your goals, but the APIs are not stable yet and won't be
for some months yet. Nor is anything changing in this area. We are not
explicitly supporting selective resolution except through the addition of
criteria for suppressing specific data connectors.

>Also, I noticed that only the 2.5 version of the Idp supports monitoring
>a directory for new metadata.

You are confusing the SP with the IdP. There is no 2.5 IdP nor is that
feature in of the Java code.

> Would it be easy for me to port support for this back to 2.4?

Nothing to port, it would be a new plugin.

>  Or better yet, is there a recommended way for me to trigger the Idp to
>refresh its metadata rather than monitoring file access times?  Since the
>configuration of the SP metadata is driven by our product, I would
>ideally like to send a request to the Idp alerting it to refresh the
>metadata for the SP identified in the request.   Is there an existing or
>better way to do this now?

Not right now. There's no programmatic access to it. There will be in V3,
and I think Brent ported the change to allow that on the metadata API in
V2, but I could be wrong, and there's nothing exposing that API right now.

-- Scott