Pass NameID as plain text

[David P]

Our SP is checking for the NameID in plain text. Right now it's being encrypted despite me specifying it not to be. Here's the XML dump:

<saml:NameID SPNameQualifier="http://www.webtma.net" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_31079808ff3e27e5f5f28097e903d2dcedf359366e</saml:NameID>

Here is my idp-hosted:

$metadata['__DYNAMIC:1__'] = array(

/*

* The hostname of the server (VHOST) that will use this SAML entity.

*

* Can be '__DEFAULT__', to use this entry by default.

*/

'host' => '__DEFAULT__',

/* X.509 key and certificate. Relative to the cert directory. */

'privatekey' => 'server.pem',

'certificate' => 'server.crt',

/*

* Authentication source to use. Must be one that is configured in

* 'config/authsources.php'.

*/

'auth' => 'jefferson-ldap',

/* Uncomment the following to use the uri NameFormat on attributes. */

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

'nameid.encryption' => false,

'authproc' => array(

// Convert LDAP names to oids.

100 => array('class' => 'core:AttributeMap', 'name2oid'),

),

);

And sp-remote:

$metadata['http://www.webtma.net'] = array (

  'entityid' => 'http://www.webtma.net',

  'contacts' => 

  array (

  ),

  'metadata-set' => 'saml20-sp-remote',

  'AssertionConsumerService' => 

  array (

    0 => 

    array (

      'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',

      'Location' => 'https://www.webtma.net/SAMLService.aspx?c=jefferson',

      'index' => 1,

      'isDefault' => true,

    ),

  ),

  'SingleLogoutService' => 

  array (

  ),

  'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',

);

Is there another configuration I am unaware of?

[Tom Scavo]

On Thu, Jun 6, 2013 at 3:07 PM, David P <david.p...@gmail.com> wrote:
> Our SP is checking for the NameID in plain text. Right now it's being
> encrypted despite me specifying it not to be. Here's the XML dump:
>
> <saml:NameID SPNameQualifier="http://www.webtma.net"
> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_31079808ff3e27e5f5f28097e903d2dcedf359366e</saml:NameID>

That's not encrypted. A transient NameID is normally opaque (as above).

Tom

[David P]

So, the SP should know how to decrypt this? Or, have the value of NameID stored on their end in the same obfuscation?

[Nate Klingenstein]

David,

It can't be decrypted and it shouldn't be stored or used.  It's basically a session identifier and nothing more.  If you need something else passed as a NameID, you should inform your partner IdP.

Thanks,

Nate.

--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Daniel Tsosie]

I'd further include looking at the name id possibilities at

http://simplesamlphp.org/docs/1.11/saml:nameid

As you can see, it has a variety of possible cases.

-Dan Tsosie

[David P]

We are the IdP, so I know that our end of the application is working correctly. I cannot speak for our SP in this regard, as they said all they check for is the NameID value to verify the account is valid (including the assertion and tokens, also). And in this case, they are checking for a plain text value of the NameID; plus, I have no experience being a SP, either.

[Peter Schober]

* David P <david.p...@gmail.com> [2013-06-07 15:07]:

> We are the IdP, so I know that our end of the application is working
> correctly. I cannot speak for our SP in this regard, as they said all they
> check for is the NameID value to verify the account is valid (including the
> assertion and tokens, also). And in this case, they are checking for a
> plain text value of the NameID; plus, I have no experience being a SP,
> either.

As has been said: It's not encrypted, it is plaintext (if ugly).

To add a bit to that: The reason it shouldn't be stored is that the
type of NameID used here is "transient", which means just that. (I.e.,
it's not suitable to even identity the same subject on the next
login.). Other NameID types ("persistent") are well-suited as a stable
identifier for a subject.

Based on that a transient NameID also unsuitable to say anything about
whether "the account is valid" (which doesn't mean anything specific
in a federated context, I would think). The authentication assertion
will tell the SP something along the lines of "valid at the IdP", and
the SP would need to perform any authorization based on attributes
that came with the attribute assertion.

None of this can be achieved (or has much to do) with a transient
NameID.
-peter

[David P]

Thank you for the clarification on the issue. So, in summation, it should neither be plain text or trusted for any form of identity.

[Peter Schober]

* David P <david.p...@gmail.com> [2013-06-07 17:10]:

> Thank you for the clarification on the issue. So, in summation, it should
> neither be plain text or trusted for any form of identity.

Mostly yes to the latter (not usable as identifier other than
temporily). Mostly no to the former (it /is/ plain text), but it's
slightly complicated by your choice of words.

On the wire the attribute (and it's qualifiers) is presented in an XML
structure. For some that still passes as "plain text", though within
SAML it's not a simple string (but structured).
So depending on what you mean with plain text the answer will change.
Best to avoid that term here.

And while you can encrypt NameIDs within SAML...
1. that doesn't make too much sense with transient ones
2. that is not the case here
3. the encryption only covers the "transport", i.e., is undone by the
SAML SP upon reception. So even there it would be considered "plain
text" at the SP.

With SAML2 most people and deployments simply ignore transient NameIDs
and you probably should too.
-peter

[David P]

Extra thanks for the follow-up. I didn't have to get involved before dealing with the NameID, so I'm hoping to avoid forever more after this situation.

[Dubravko Vončina]

Hi David,

I'm not sure if you still need it, but If you don't mind modifying your
simpleSAMLphp source code a bit, here is the 'solution' which works for me:


1. You'll have to edit file

/modules/saml/lib/Auth/Process/PersistentNameID.php

and replace the line:

return sha1($uidData);

with the following block of code:

if( $state['Destination']['entityid'] == 'http://www.webtma.net' ){
return $uid;
}
else{
return sha1($uidData);
}


2. Your sp-remote configuration should look like (you have to replace
'nameid_attribute' with name of the attribute whose value you want to
pass as NameID):

$metadata['http://www.webtma.net'] = array (
'entityid' => 'http://www.webtma.net',
'contacts' => array (
),
'metadata-set' => 'saml20-sp-remote',
'AssertionConsumerService' => array (
0 => array (
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
'Location' => 'https://www.webtma.net/SAMLService.aspx?c=jefferson',
'index' => 1,
'isDefault' => true,
),
),
'SingleLogoutService' => array (
),

'authproc' => array(
20 => array(
'class' => 'saml:PersistentNameID',
'attribute' => 'nameid_attribute',
'NameQualifier' => TRUE,
),
),
'attributes.NameFormat' =>
'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
);


I'm aware this may be not the most elegant way of solving things, but
it's the only solution that I came up with and so far it works for me.

Best regards,

--
Dubravko Voncina
Information Systems and Applications Department
University of Zagreb, University Computing Centre, www.srce.unizg.hr
dubravko...@srce.hr, tel: +385 1 616 5852, fax: +385 1 616 5559

On 06/07/2013 05:44 PM, David P wrote:
> Extra thanks for the follow-up. I didn't have to get involved before
> dealing with the NameID, so I'm hoping to avoid forever more after this
> situation.
>
> On Friday, June 7, 2013 11:29:21 AM UTC-4, Peter Schober wrote:
>

> * David P <david.p...@gmail.com <javascript:>> [2013-06-07 17:10]:

> > Thank you for the clarification on the issue. So, in summation,
> it should
> > neither be plain text or trusted for any form of identity.
>
> Mostly yes to the latter (not usable as identifier other than
> temporily). Mostly no to the former (it /is/ plain text), but it's
> slightly complicated by your choice of words.
>
> On the wire the attribute (and it's qualifiers) is presented in an XML
> structure. For some that still passes as "plain text", though within
> SAML it's not a simple string (but structured).
> So depending on what you mean with plain text the answer will change.
> Best to avoid that term here.
>
> And while you can encrypt NameIDs within SAML...
> 1. that doesn't make too much sense with transient ones
> 2. that is not the case here
> 3. the encryption only covers the "transport", i.e., is undone by the
> SAML SP upon reception. So even there it would be considered "plain
> text" at the SP.
>
> With SAML2 most people and deployments simply ignore transient NameIDs
> and you probably should too.
> -peter
>

[Peter Schober]

* Dubravko Vončina <dubravko...@srce.hr> [2013-06-07 17:51]:

> I'm aware this may be not the most elegant way of solving things,
> but it's the only solution that I came up with and so far it works
> for me.

To achive what, exactly?
Also your modifications are specific to persistent NameIDs (AFAICT)
and this thread was about NameIDs of type transient.
-peter