Metarefresh and AttributeConsumingService

[Jeffrey Krug]

I was trying to use the Metarefresh module to configure a Trusted SP for my Simple SAML Identity Provider.  This SP's metadata includes an AttributeConsumingService entry specifying the list of attributes the service wants.  When that is converted into Simple SAML configuration I get something like this:

  'attributes' =>

  array (

    0 => 'gfipm:2.0:user:GivenName',

    1 => 'gfipm:2.0:user:SurName',

    2 => 'gfipm:2.0:user:FederationId',

    3 => 'gfipm:2.0:user:EmailAddressText',

  ),

  'attributes.NameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',

  'name' =>

  array (

    'en' => 'GFIPM Reference Service Provider',

  ),

  'description' =>

  array (

  ),

None of the above looks immediately problematic, but when the above shows up in the PHP config (saml20-sp-remote.php) it looks like the authproc that I have configured in saml20-idp-hosted.php is not being executed properly.  My authproc uses the smartid module which fails because smartid generates an ID based on an internal attribute not in the above list (which then gets mapped to one of the above in a later authproc map)...  I commented out the smartid module from the authproc in saml20-idp-hosted.php assuming there was a bug within it that I would have to debug, and at this point I get no errors but simplesaml sends no attributes to the SP (there is a valid SAML Assertion and Response otherwise, but no AttributeStatement is included).  

If I delete the above section from saml20-sp-remote.php everything works fine.

Should I move the authproc filters into the base config/config.php?  If simplesamlphp is going to be smart about only sending attributes that are specifically requested that would be a fantastic feature, but right now, the act of requesting specific attributes causes no attributes to be sent, which cannot obviously be correct...  

Thanks,
Jeff

[Jeffrey Krug]

To clarify, moving my authproc config from saml20-idp-hosted.php into config.php did not fix the problem.  If I delete the attributes variable, everything works (admittedly sending more than the requested attributes, but sending attributes and successfully running the smartid module).  

--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at http://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.

[Peter Schober]

* Jeffrey Krug <gtk...@gmail.com> [2015-08-18 23:34]:

> My authproc uses the smartid module which fails because smartid
> generates an ID based on an internal attribute not in the above list
> (which then gets mapped to one of the above in a later authproc
> map)...

Unless you regularly re-import signed SAML Metadata from that SP you
can tune the requested attributes in that SP's metadata to your
liking, e.g. by adding a reference to the "internal attribute".

Not sure I understand the problem, though. Is it a smartid module
problem (and what would be the expected behaviour, given concrete
configuration)?
Or should SSP change its behaviour about requested attributs?
How specifically should it behave, in your opinion?
-peter

[Jeffrey Krug]

My concern is that if the requested attributes are present, the mappings I have put into authproc (either in the saml20-idp-hosted file or the config.php file) are not executing...  Maybe I should not have mentioned the smartid module as that's not relevant to the bug (just a side effect of it).  

I have authproc mappings for all of the requested attributes, but no attributes are being sent to the SP...  I cannot place those authproc mappings into the SP configuration as the saml20-sp-remote.php should always be generated from metadata (the metadata is going to change and there will be hundreds of SPs eventually when this gets moved into production).  Furthermore, it does make sense to me that the definitions of attributes would change based on the recipient.  The attributes you chose to send might/should change, but how to define those attributes would not.

To me, the mappings in authproc should all happen and then the requested attributes in the saml20-sp-remote.php config would simply filter what is sent.   It should not ignore the mappings configured at the IDP based on the remote SP's request.

[Jaime Perez Crespo]

Hi Jeffrey,

It looks like your problem is a configuration issue. What you are describing sounds like the core:AttributeLimit authproc being executed before your smartid authproc, hence leading to the problem. However, that’s something you configure yourself. Just check the priority given to both authprocs, and give core:AttributeLimit a bigger number. Just in case, priorities are assigned by means of the number used to index the authproc array. So an authproc with index 0 would execute first, and an authproc with index 100 would execute after one with index 50. Priorities are absolute, meaning all the authproc arrays are merged and consequently the priorities are absolute and can be reassigned in case of collisions.

Conclusion: make sure your core:AttributeLimit authproc has a low priority:

config/config.php:
—>8—
‘authproc.idp’ => array(
9999 => ‘core:AttributeLimit’,
),
—8<—

metadata/saml20-idp-hosted.php:
—>8—
‘authproc’ => array(
50 => ‘smartid’,
),
—8<—

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Jeffrey Krug]

Brilliant.  I guess I should have realized how that worked, but I didn't.  I changed the config based on your advice and everything is working fine.  I appreciate the information!

Thanks,
Jeff