3.2.1: IdPPrincipalAttribute & attribute filtering policies

[Misagh Moayyed]

Perfect. Thanks. Got that all worked out for the POC. 

-- 
Misagh

From: Rod Widdowson <rdw at steadingsoftware.com>
Reply: Shib Dev <dev at shibboleth.net>
Date: August 25, 2016 at 2:48:53 AM
To: 'Shib Dev' <dev at shibboleth.net>
Subject:  RE: 3.2.1: IdPPrincipalAttribute & attribute filtering policies  

> What might I have to do to let the current set of attributes handle what is
> resolved outside the IdP from those principal attributes of the external
> context?

I'm pretty sure we went round this loop a couple of months ago, but I cannot remember enough keywords to be able to locate the conversation… I think it was to do some gate-waying that a customer wanted. I think it ended up here:

https://wiki.shibboleth.net/confluence/display/~rdw@iay.org.uk/Attribute+Flow+in+the+IdP+-+A+Discussion+document

One of the issues was to do with the deficiencies in the IdpAttribute.clone() mechanism.

Another was the basic ugliness of the configuration involved. In order to release an attribute you need to specify encoders and the current mechanism means that you need to define the attribute resolvers for each one

This of course answers your question

> What might I have to do to let the current set of attributes handle what is resolved outside the IdP from those principal attributes of the external context?

In order that that should happen you need to make sure that they are resolved.  

This is more than achievable, but it's going to be a prototype or a local implementation since if we want to address this I would want to address the root cause.

In your situation I would:

- Write a ScriptedConnector to pluck the attribute values from wherever you have squirreled them (you can write java if you want but scripting will be quicker). I would *NOT* use the passed in IdPAttributes. I am not sure and hence would make absolutely no guarantees about thread safety and hence information leakage.  

- Then write a series of Simple attribute definitions which depend on the connector and have the appropriate SourceID (you will need one definition for each possible input or output attribute name). These definitions attach encoders and so on to the resolved attributes.

- I'd probably conditionalize the definitions and connector  

- Then they are there for you to filter and release as usual

I would take _extreme_ care with Attribute naming - The namespaces are mostly separate but sometime overlap. I would use distinct names  

- for the IdPAttributes inside your IdPPrincipalAttribute
- for the IdPAttributes resolver by the DataConnector  
- for the Attribute Definitions  
- and (of course) for the on the wire names

There is a lot of subtlety in here and if you systematically keep the names separate you head is less likely to explode when something odd happens.

Good luck

/Rod

--  
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160825/e6762973/attachment.html>