RequestedAttributes in SP metada

[Nick Amon]

Thanks for all your responses.  

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.  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.  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?

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.

Also, I noticed that only the 2.5 version of the Idp supports monitoring a directory for new metadata.  Would it be easy for me to port support for this back to 2.4?  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?

Thanks,

Nicholas

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, December 30, 2013 10:16 AM
To: Shib Users
Subject: Re: RequestedAttributes in SP metada

On 12/30/13, 10:04 AM, "Ian Young" <ian at iay.org.uk> wrote:
>
>In other words, it appears to be looking in the peer's (SP's) metadata 
>for an attribute authority descriptor... which won't be present. I 
>don't see any evidence that it is looking at the SP's 
>RequestedAttribute information at all.

It predates even thinking about that part of metadata.

> This may be because it's possible to have many of those, but I will 
>have to leave it to someone who knows that code better to be definitive.
>
>(Scott has replied already saying that this code isn't operational, but 
>I'm not sure if the above is new information.)

I haven't looked at it lately, but I am aware of the fact that there are methods to obtain attribute ID collections for input to the resolver that have never been operational and don't return anything. If the code base wasn't headed for maintenance mode I would have cleaned that up, but since it's being thrown out, I left it alone. The AttributeAuthority layer of classes in the code are very questionable in many areas and aren't being ported over.

It is possible in isolated cases to tell the resolver to return only specific attributes but that isn't used at all in any of the code we ship.
It has been used by people calling the resolver from inside a custom login handler, to return assurance related attributes.

None of this is relevant to anybody deploying an IdP and doing basic attribute exchange.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net