sign/encrypt assertions attributes not being honoured

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

sign/encrypt assertions attributes not being honoured

sshabbir
Hello,

In trying to comply with our SP request to sign assertions, and not encrypt
them, I've added below to /relying-party.xml/

<bean parent="RelyingPartyByName"
c:relyingPartyIds="https://..../samlLogin">
                        <property name="profileConfigurations">
                        <list>
                                <bean parent="SAML2.SSO"
p:encryptAssertions="false" p:signAssertions="true"
p:encryptNameIDs="false"/>

However, the SAML response extract below suggests this does not seem to work

/<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
                    NameQualifier="https://.../idp/shibboleth"
                    SPNameQualifier="https://.../samlLogin">
*AAdzZWNyZXQxhqCyvp0AoTAcLu2yR5BufFgIHiwkFNHRH18y0F7E73EhUzyoS2FrWS1fjRCHngAAQgAeQdnzI0XCt080OG72GaeXGJlywVBn6+Z2o/xw7jPVuqsYSmhOuMi1bUzUNHYrQ6GQn5/NAk6VrhlU4IVQgOIzpHvGdsHhbKVkG4mJBUiZd6UuVOYLqUnckY/pjz3QZCQh6CPrrxnAZ2QVQw==*
</saml2:NameID>/


They are also adamant that

/NameID Format must either be not provided, or
“urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”, or
“urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified”/

Based on
https://wiki.shibboleth.net/confluence/display/IDP30/CustomNameIDGenerationConfiguration,
adding the attribute
p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
to the SAML2.SSO bean, under "RelyingPartyByName", results in a response
with no saml2:NameID entry.

In fact, I can only get that entry to appear by updating the
attribute-resolver entry as below

<AttributeDefinition  xsi:type="Simple" id="UserName"
sourceAttributeID="userName">
        <Dependency ref="scriptedAttributeConnector" />
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:2.5.4.42"
nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
encodeType="false" />
   
    </AttributeDefinition>

Thanks in advance...




-----
Syed
--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Syed
Reply | Threaded
Open this post in threaded view
|

Re: sign/encrypt assertions attributes not being honoured

Andrew Morgan
On Wed, 1 Aug 2018, sshabbir wrote:

> Hello,
>
> In trying to comply with our SP request to sign assertions, and not encrypt
> them, I've added below to /relying-party.xml/
>
> <bean parent="RelyingPartyByName"
> c:relyingPartyIds="https://..../samlLogin">
>                        <property name="profileConfigurations">
>                        <list>
>                                <bean parent="SAML2.SSO"
> p:encryptAssertions="false" p:signAssertions="true"
> p:encryptNameIDs="false"/>
>
> However, the SAML response extract below suggests this does not seem to work
>
> /<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>                    NameQualifier="https://.../idp/shibboleth"
>                    SPNameQualifier="https://.../samlLogin">
> *AAdzZWNyZXQxhqCyvp0AoTAcLu2yR5BufFgIHiwkFNHRH18y0F7E73EhUzyoS2FrWS1fjRCHngAAQgAeQdnzI0XCt080OG72GaeXGJlywVBn6+Z2o/xw7jPVuqsYSmhOuMi1bUzUNHYrQ6GQn5/NAk6VrhlU4IVQgOIzpHvGdsHhbKVkG4mJBUiZd6UuVOYLqUnckY/pjz3QZCQh6CPrrxnAZ2QVQw==*
> </saml2:NameID>/
That is a correctly formatted transient NameID.  It is a base64-encoded
hash that is generated by the IDP, unique to each SAML response.

BTW, the relying-party.xml configuration you provided above is correct to
disable encryption and sign assertions.

> They are also adamant that
>
> /NameID Format must either be not provided, or
> “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”, or
> “urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified”/
>
> Based on
> https://wiki.shibboleth.net/confluence/display/IDP30/CustomNameIDGenerationConfiguration,
> adding the attribute
> p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> to the SAML2.SSO bean, under "RelyingPartyByName", results in a response
> with no saml2:NameID entry.
>
> In fact, I can only get that entry to appear by updating the
> attribute-resolver entry as below
>
> <AttributeDefinition  xsi:type="Simple" id="UserName"
> sourceAttributeID="userName">
>        <Dependency ref="scriptedAttributeConnector" />
>        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:2.5.4.42"
> nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> encodeType="false" />
>
>    </AttributeDefinition>
What value do they actually want in the NameID?  Your attributeDefinition
suggests you want to put an unscoped username in the field.  If that is
true, the format should not be "transient".

The documentation to generate a NameID is here:

   https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration

Read the "Format Selection" section carefully...

Let us know if you have additional questions.

Thanks,
  Andy
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: sign/encrypt assertions attributes not being honoured

Nate Klingenstein-2
In reply to this post by sshabbir
Syed,

In order for a NameID to be released, you need to have the attribute available(which it probably is), it needs to be a candidate for a NameID for this relying party(which it probably isn't), and it needs to be the one that is chosen in any given transaction.


In this case, you're adding a nameFormat to an attribute.  They're looking for a NameID, which is totally different.  You'll want to revert to the default URI nameFormat for the attribute.


Also remember that relying-party.xml operates on a first-match, first-serve basis.  You might have an entry without an activationCondition further up in your file that is superceding other configuration.

Take care,
Nate.

On Wed, Aug 1, 2018 at 10:56 AM, sshabbir <[hidden email]> wrote:
Hello,

In trying to comply with our SP request to sign assertions, and not encrypt
them, I've added below to /relying-party.xml/

<bean parent="RelyingPartyByName"
c:relyingPartyIds="https://..../samlLogin">
                        <property name="profileConfigurations">
                        <list>
                                <bean parent="SAML2.SSO"
p:encryptAssertions="false" p:signAssertions="true"
p:encryptNameIDs="false"/>

However, the SAML response extract below suggests this does not seem to work

/<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
                    NameQualifier="https://.../idp/shibboleth"
                    SPNameQualifier="https://.../samlLogin">
*AAdzZWNyZXQxhqCyvp0AoTAcLu2yR5BufFgIHiwkFNHRH18y0F7E73EhUzyoS2FrWS1fjRCHngAAQgAeQdnzI0XCt080OG72GaeXGJlywVBn6+Z2o/xw7jPVuqsYSmhOuMi1bUzUNHYrQ6GQn5/NAk6VrhlU4IVQgOIzpHvGdsHhbKVkG4mJBUiZd6UuVOYLqUnckY/pjz3QZCQh6CPrrxnAZ2QVQw==*
</saml2:NameID>/


They are also adamant that

/NameID Format must either be not provided, or
“urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”, or
“urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified”/

Based on
https://wiki.shibboleth.net/confluence/display/IDP30/CustomNameIDGenerationConfiguration,
adding the attribute
p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
to the SAML2.SSO bean, under "RelyingPartyByName", results in a response
with no saml2:NameID entry.

In fact, I can only get that entry to appear by updating the
attribute-resolver entry as below

<AttributeDefinition  xsi:type="Simple" id="UserName"
sourceAttributeID="userName">
        <Dependency ref="scriptedAttributeConnector" />
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:2.5.4.42"
nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
encodeType="false" />

    </AttributeDefinition>

Thanks in advance...




-----
Syed
--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: sign/encrypt assertions attributes not being honoured

sshabbir
In reply to this post by Andrew Morgan
>What value do they actually want in the NameID?  Your attributeDefinition
>suggests you want to put an unscoped username in the field.  If that is
>true, the format should not be "transient".

The value required in NameID is the username attribute, and format needs to
be "unspecified", urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified. It
seems my AttributeDefinition is incorrect, and not sure what default urn
format is for "username". In our case username is unique, should I use "uid"
urn format

<AttributeDefinition  xsi:type="Simple" id="userName"
sourceAttributeID="userName">
        <Dependency ref="scriptedAttributeConnector" />
          <AttributeEncoder xsi:type="SAML2String" name="urn:oid:2.5.4.42"
encodeType="false" />
    </AttributeDefinition>


> The documentation to generate a NameID is here:
>
>  
> https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration
>
> Read the "Format Selection" section carefully...

The SP metadata, or request, does not contain any required nameformat
policy:

<AuthnRequest ID="samlrequest_a269d35d782d4865b69a59d0b694fe61"
              Version="2.0"
              IssueInstant="2018-08-02T09:40:29.8535234Z"
             
AssertionConsumerServiceURL="https://...../login/samlLogin.d2l"
              xmlns="urn:oasis:names:tc:SAML:2.0:protocol">
  <Issuer
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://.../samlLogin</Issuer>
</AuthnRequest>

So, I've tried to create a custom SSO bean, with precedence values, and
using that in "RelyingPartyByName". However, the nameID value is not
released in the response

<bean id="SAML2.SSO.custom" parent="SAML2.SSO"
          p:nameIDFormatPrecedence="#{{
            'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',
            'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'}}" />




-----
Syed
--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Syed
Reply | Threaded
Open this post in threaded view
|

Re: sign/encrypt assertions attributes not being honoured

Peter Schober
* sshabbir <[hidden email]> [2018-08-02 13:01]:
> >What value do they actually want in the NameID?  Your
> >attributeDefinition suggests you want to put an unscoped username
> >in the field.  If that is true, the format should not be
> >"transient".
>
> The value required in NameID is the username attribute, and format
> needs to be "unspecified",
> urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified.

The general recommendation from this community is to not believe such
claims and try to send the expected data in any suitable format,
e.g. using the attribute's formal name (for the "uid" attribute that
would be "urn:oid:0.9.2342.19200300.100.1.1").

Only when you've determined that not to work should you configure the
system to use "unspecified".

> It seems my AttributeDefinition is incorrect, and not sure what
> default urn format is for "username". In our case username is
> unique, should I use "uid" urn format

No. An AttributeDefintion is for defining attributes. If you need to
define a NameID with a value based on an attribute you do that in the
NameID configuration, in conf/saml-nameid.xml, e.g.:

<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
  p:omitQualifiers="true"
  p:format="urn:oid:0.9.2342.19200300.100.1.1"
  p:attributeSourceIds="#{ {'uid'} }" />

This would define a NameID of the given format (using the formal
attribute name for "uid" as an example; for the pathological case set
that to "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
instead) that gets its value from the AttributeDefinition with the
id="uid". So define the uid attribute first in your resolver, without
any references to NameIDs of their formats.

Then override the NameID predecence in conf/relying-party.xml and only
list the desired format (which you also defined above), and only for
that broken SP in question, e.g.:

<bean parent="RelyingPartyByName" c:relyingPartyIds="#{{'https://sp.example.org/entity'}}">
  <property name="profileConfigurations">
    <list>
      <bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oid:0.9.2342.19200300.100.1.1" />
    </list>
  </property>
</bean>

(Again change the format to unspecified if positively required.)

Testing all this is simple using the provided "aacli" tool, and
potentially reloading the AttributeResolver and NameID services from
the command line as needed (no restarting of the IDP necessary, no
logging in to the SP, no entering passwords, no watching log files, etc.):

Running the aacli with saml NameIDs shown:

$ /opt/shibboleth-idp/bin/aacli.sh --saml2 -n SOME_USERID -r SOME_SP_ENTITYID

Reloading the resolver after you've defined the uid attribute:

$ /opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.AttributeResolverService

Reloading the NameID generation config after you've defined the
attribute-sourced NameID:

$ /opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.NameIdentifierGenerationService

Depending on other settings in the IDP you may also have to release
the underlying attribute to the SP, so if in doubt release the "uid"
attribute to that SP in your attribute-filter.xml, too, and re-try.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: sign/encrypt assertions attributes not being honoured

sshabbir
This post was updated on .
Hello,

and thanks that all worked.

For anyone else stumbling onto same issue, I'll summarize my changes based on
Peters' comment above.

To achieve an IDP response, making use of "unspecified", as below

<saml2:Subject>
      <saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
                    NameQualifier="https://..../idp/shibboleth"
                    SPNameQualifier="https://..../samlLogin">
           id2001251
     </saml2:NameID>
......

Update your attribute resolver as below

<AttributeDefinition  xsi:type="Simple" id="userName"
sourceAttributeID="userName">
        <Dependency ref="scriptedAttributeConnector" />     
       <AttributeEncoder xsi:type="SAML2String"
<b>name="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"*  
encodeType="false" />
    </AttributeDefinition>


relying-party.xml,


<bean parent="RelyingPartyByName"
c:relyingPartyIds="#{{'https://..../samlLogin'}}">
                        <property name="profileConfigurations">
                        <list>
                         <bean parent="SAML2.SSO" p:encryptAssertions="false"
p:signAssertions="true" p:encryptNameIDs="false"
                               
<b>p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
/>*
                        </list>
                        </property>
                </bean>       

saml-nameid.xml

<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
            p:attributeSourceIds="#{ {'userName'} }" />



-----
Syed
--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net
Syed
Reply | Threaded
Open this post in threaded view
|

Re: sign/encrypt assertions attributes not being honoured

Peter Schober
* sshabbir <[hidden email]> [2018-08-02 17:17]:
> Update your attribute resolver as below
>
> <AttributeDefinition  xsi:type="Simple" id="userName"
> sourceAttributeID="userName">
>         <Dependency ref="scriptedAttributeConnector" />    
>        <AttributeEncoder xsi:type="SAML2String"
> name="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" encodeType="false" />
>     </AttributeDefinition>

No, use an encoder that's apppropiate for "userName" in the general
context, i.e., don't special-case what a "userName" is just because
you might /also/ use it as the basis for a NameID sometimes.
(I suggested the formal name of uid/userid from RFC4519, so the name
would be "urn:oid:0.9.2342.19200300.100.1.1" in the encoder, not that
the "unspecified" urn above).

The encoding as a NameID is *not* done in your provided example, here
you merely define an ordinary attribute.  It's the reference to this
attribute from saml-nameid.xml that turns it into a NameID when
needed.

> p:encryptNameIDs="false"

Encryption of NameIDs defaults to false for many, many years now, so
you can remove that, simplifying your override a bit.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]