IDP-initiaded SSO or IdPUnsolicitedSSO

[Kevin P. Foote]

On Wed, 16 Oct 2013, Jehan Procaccia wrote:

> <resolver:AttributeDefinition id="email" xsi:type="Simple"
> xmlns="urn:mace:shibboleth:2.0:resolver:ad"
>         sourceAttributeID="mail">
>         <resolver:Dependency ref="ldapTMSP" />
>         <resolver:AttributeEncoder xsi:type="SAML1String"
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>             name="urn:mace:dir:attribute-def:mail" />
>         <resolver:AttributeEncoder xsi:type="SAML2String"
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>             name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" />
>     </resolver:AttributeDefinition>
>
> So if I understood well, that attribute name is "email" (not mail right !?)
> it's nameFormat is either SAML1String or SAML2String
> and it's not a NameID .
>
> If I want it to become a NameID it must be of type
> xsi:type="SAML2StringNameID" , but is it possible to sent multiple
> NameID attributes, my IDP already sends
> AttributeDefinition id="eduPersonTargetedID" xsi:type="SAML2NameID"

Of the available attributes that are encoded to the proper NameID Format
during the resolution and release phase, the Shib IdP will only pick one 
to send as the NameID of the assertion.

Stated differently you can attach NameID encoders to multiple attribute
definitions during the resolver stage.  During the filtering and release
stage a single NameID value will be chosen from the pool of available 
attributes that can be released to a given RP.

You can force which one is chosen by limiting the available attributes
at release or using the precedence capabilities (see Selection Process
linked below).

<https://wiki.shibboleth.net/confluence/display/SHIB2/IdPNameIdentifier>

------
thanks
  kevin.foote