Problem with Scope of attributes
1,616 views
Skip to first unread message
weisman491
Nov 12, 2014, 4:18:04 PM11/12/14
to simple...@googlegroups.com
Hey this seems pretty simple but I've been at it for a few days now. Basically our connection to an SP is working up until metadata is passed back to the SP. Our IDP is simplesamlphp. We're connecting to a shib SP
Their logs indicate this:
2014-11-12 15:18:56 DEBUG Shibboleth.AttributeDecoder.String [33]: decoding SimpleAttribute (uid) from SAML 2 Attribute (urn:oid:0.9.2342.19200300.100.1.1) with 1 value(s)
2014-11-12 15:18:56 DEBUG Shibboleth.AttributeDecoder.Scoped [33]: decoding ScopedAttribute (eppn) from SAML 2 Attribute (urn:oid:1.3.6.1.4.1.5923.1.1.1.6) with 1 value(s)
2014-11-12 15:18:56 DEBUG Shibboleth.AttributeDecoder.Scoped [33]: decoding ScopedAttribute (affiliation) from SAML 2 Attribute (urn:oid:1.3.6.1.4.1.5923.1.1.1.9) with 1 value(s)
2014-11-12 15:18:56 DEBUG Shibboleth.AttributeDecoder.String [33]: decoding SimpleAttribute (unscoped-affiliation) from SAML 2 Attribute (urn:oid:1.3.6.1.4.1.5923.1.1.1.1) with 1 value(s)
2014-11-12 15:18:56 DEBUG Shibboleth.AttributeFilter [33]: filtering 4 attribute(s) from (example.edu)
2014-11-12 15:18:56 DEBUG Shibboleth.AttributeFilter [33]: applying filtering rule(s) for attribute (unscoped-affiliation) from (example.edu)
2014-11-12 15:18:56 DEBUG Shibboleth.AttributeFilter [33]: applying filtering rule(s) for attribute (affiliation) from (example.edu)
2014-11-12 15:18:56 WARN Shibboleth.AttributeFilter [33]: removed value at position (0) of attribute (affiliation) from (example.edu)
2014-11-12 15:18:56 DEBUG Shibboleth.AttributeFilter [33]: applying filtering rule(s) for attribute (eppn) from (example.edu)
2014-11-12 15:18:56 WARN Shibboleth.AttributeFilter [33]: removed value at position (0) of attribute (eppn) from (example.edu)
Now from my understanding this warning means it is because the values are not "scoped" even though the one, urn:oid:1.3.6.1.4.1.5923.1.1.1.9 is the eduPersonScopedAffiliation which is scoped by default correct?
The other value is a modified attribute I had to map which contains the users email and is: 'userPrincipalName' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', which I think userPrincipalName is not scoped by default.
If these need to be scoped how do I do that in simplesamlphp's metadata? and if not why are they not being passed correctly? Any thoughts I'm pretty stuck.
Thanks!
Tyler
Tom Scavo
Nov 12, 2014, 5:42:58 PM11/12/14
to simpleSAMLphp
On Wed, Nov 12, 2014 at 4:18 PM, weisman491 <weism...@gmail.com> wrote:
>
> Now from my understanding this warning means it is because the values are
> not "scoped" even though the one, urn:oid:1.3.6.1.4.1.5923.1.1.1.9 is the
> eduPersonScopedAffiliation which is scoped by default correct?
> The other value is a modified attribute I had to map which contains the
> users email and is: 'userPrincipalName' =>
> 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', which I think userPrincipalName is not
> scoped by default.
Both of those attributes are scoped by definition (see
>
> Now from my understanding this warning means it is because the values are
> not "scoped" even though the one, urn:oid:1.3.6.1.4.1.5923.1.1.1.9 is the
> eduPersonScopedAffiliation which is scoped by default correct?
> The other value is a modified attribute I had to map which contains the
> users email and is: 'userPrincipalName' =>
> 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', which I think userPrincipalName is not
> scoped by default.
"ScopedAttribute" designator at the top of the trace) and so a relying
party should only accept them if the Scope element appears in metadata
(which apparently is not the case). A Shib SP can be configured to
bypass the scope check but that would go against the entire notion of
"scope" so the onus is on you, the IdP, to supply the correct metadata
to begin with.
> If these need to be scoped how do I do that in simplesamlphp's metadata? and
> if not why are they not being passed correctly? Any thoughts I'm pretty
> stuck.
but the idea is not for you, the IdP operator, to assert a Scope in
metadata, but for a trusted 3rd party (such as a federation) to assert
the Scope element in metadata. The trusted 3rd party prevents the IdP
from asserted scoped attributes having arbitrary scope values.
Tom
Peter Schober
Nov 13, 2014, 2:43:07 AM11/13/14
to simple...@googlegroups.com
* weisman491 <weism...@gmail.com> [2014-11-12 22:18]:
not userPrincipalName (whatever that is, I think some M$ thing).
One (somewhat weird) way to produce scoped attributes I found a long
time ago, in the authproc.idp filter section:
52 => array(
'class' => 'core:AttributeAdd',
'ScopedFoo' => 'f...@example.org, // to extract the scope from
// or use eduPersonScopedAffiliation below
),
53 => array(
'class' => 'core:ScopeAttribute',
'scopeAttribute' => 'ScopedFoo', // grab scope from this, defined above
'sourceAttribute' => 'uid', // and slap it onto that one
'targetAttribute' => 'eduPersonPrincipalName',
),
This will turn uid attributes (and values) into b...@example.org-valued
ePPNs.
As for the IDP's metadata: Unless SimpleSAMLphp supports to insert the
shibmd:Scope extension (which I'm not sure about) you can add this to the
resulting XML yourself, or via an XSLT process doing that dynamically,
for example. But as Tom said, if that's element is self-asserted too,
without any checking, it's of no value: Scope checking allows an SP to
prevent it from accepting scoped attrbutes from one IDP being scoped
for some other IDP (idp/attribute impersonation).
-peter
> The other value is a modified attribute I had to map which contains the
> users email and is: 'userPrincipalName' =>
> 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', which I think userPrincipalName is not
> scoped by default.
Note that urn:oid:1.3.6.1.4.1.5923.1.1.1.6 is eduPersonPrincipalName,
> users email and is: 'userPrincipalName' =>
> 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', which I think userPrincipalName is not
> scoped by default.
not userPrincipalName (whatever that is, I think some M$ thing).
One (somewhat weird) way to produce scoped attributes I found a long
time ago, in the authproc.idp filter section:
52 => array(
'class' => 'core:AttributeAdd',
'ScopedFoo' => 'f...@example.org, // to extract the scope from
// or use eduPersonScopedAffiliation below
),
53 => array(
'class' => 'core:ScopeAttribute',
'scopeAttribute' => 'ScopedFoo', // grab scope from this, defined above
'sourceAttribute' => 'uid', // and slap it onto that one
'targetAttribute' => 'eduPersonPrincipalName',
),
This will turn uid attributes (and values) into b...@example.org-valued
ePPNs.
As for the IDP's metadata: Unless SimpleSAMLphp supports to insert the
shibmd:Scope extension (which I'm not sure about) you can add this to the
resulting XML yourself, or via an XSLT process doing that dynamically,
for example. But as Tom said, if that's element is self-asserted too,
without any checking, it's of no value: Scope checking allows an SP to
prevent it from accepting scoped attrbutes from one IDP being scoped
for some other IDP (idp/attribute impersonation).
-peter
weisman491
Nov 13, 2014, 9:48:52 AM11/13/14
to simple...@googlegroups.com, peter....@univie.ac.at
Thanks for the response they help a lot, this is the route I was starting to head down myself. So in my example I have this:
'attributes'=>array('userPrincipalName','sAMAccountName','uid'), //all they really need and then I add the others
'authproc' => array(
50 => array(
'class' => 'core:AttributeAdd',
'eduPersonScopedAffiliation' => array('mem...@university.edu','mem...@sub.university.edu'),
'urn:oid:1.3.6.1.4.1.5923.1.1.1.1' => array('member','student'),
),
51 => array(
'class' => 'core:AttributeMap',
'sAMAccountName' => 'urn:oid:0.9.2342.19200300.100.1.1',
'userPrincipalName' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
),
52 => array(
'class' => 'core:ScopeAttribute',
'scopeAttribute' => 'eduPersonScopedAffiliation',
'sourceAttribute' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
'targetAttribute' => 'eduPersonPrincipalName',
),
// Convert LDAP names to oids.
30 => array('class' => 'core:AttributeMap', 'name2oid'),
),
Anyone see why urn:oid:1.3.6.1.4.1.5923.1.1.1.6 which I have to map to 'userPrincipalName since that is what contains our users emails in ldap isn't still getting scoped. For some reason it says eduPersonScopedAffiliation isn't scoped either. Even though it should be by default. I have to convert to oid's since that is what the SP uses.
sAMAccountName passes correctly and urn:oid:1.3.6.1.4.1.5923.1.1.1.1 passes correctly sometimes. I wonder if I just have the order messed up in the authproc array? or something else.
Thanks again for the earlier responses
Tyler
Peter Schober
Nov 13, 2014, 10:04:34 AM11/13/14
to simple...@googlegroups.com
* weisman491 <weism...@gmail.com> [2014-11-13 15:48]:
userPrincipalName, see one of my previous mails about that.
2. Not sure about your use and mixture of basic names
("sAMAccountName") and OID-based URN names in the same config.
Why specifically are you doing that?
I'd use basic names throughout the config and only convert them to
oids at the end (your number 30). So keep the names basic and move the
name2oid map to run after all the others, at least for sanity.
> Anyone see why urn:oid:1.3.6.1.4.1.5923.1.1.1.6 which I have to map
> to 'userPrincipalName since that is what contains our users emails
> in ldap isn't still getting scoped.
"urn:oid:1.3.6.1.4.1.5923.1.1.1.6" is not "userPrincipalName", but as
long as you're only sending the OID-based URN (and with the correct
nameFormat) the friendlyName doesn't matter.
Also, "urn:oid:1.3.6.1.4.1.5923.1.1.1.6" is not defined to be the
subject's email address, though you can choose to implement it that
way (i.e, it's syntactically equivalent, though not semantically).
If you want to send the subject's email address why not issue the
attribute "urn:oid:0.9.2342.19200300.100.1.3" (mail) instead?
Also, what do you actually send in the assertion? Hard to say what's
wrong without seeing what actually goes out.
> For some reason it says eduPersonScopedAffiliation isn't scoped
> either.
Please post an example from the XML that get's issued.
You could grab it from your logs (on debug), or, in case the assertion
is not encrypted, from the browser, e.g. using the SAMLtracer plugin
for Mozilla Firefox.
> Even though it should be by default. I have to convert to oid's
> since that is what the SP uses.
eduPerson attributes are defined to use URIs as nameFormat, as to
their specification for usage in SAML,
http://macedir.org/docs/internet2-mace-dir-saml-attributes-latest.pdf
-peter
> 'authproc' => array(
>
> 50 => array(
> 'class' => 'core:AttributeAdd',
>
> 'eduPersonScopedAffiliation' =>
> array('mem...@university.edu','mem...@sub.university.edu'),
> 'urn:oid:1.3.6.1.4.1.5923.1.1.1.1' => array('member','student'),
> ),
> 51 => array(
> 'class' => 'core:AttributeMap',
> 'sAMAccountName' => 'urn:oid:0.9.2342.19200300.100.1.1',
> 'userPrincipalName' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
> ),
> 52 => array(
> 'class' => 'core:ScopeAttribute',
> 'scopeAttribute' => 'eduPersonScopedAffiliation',
> 'sourceAttribute' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
> 'targetAttribute' => 'eduPersonPrincipalName',
> ),
> // Convert LDAP names to oids.
> 30 => array('class' => 'core:AttributeMap', 'name2oid'),
1. Note that "urn:oid:1.3.6.1.4.1.5923.1.1.1.6" is NOT
>
> 50 => array(
> 'class' => 'core:AttributeAdd',
>
> 'eduPersonScopedAffiliation' =>
> array('mem...@university.edu','mem...@sub.university.edu'),
> 'urn:oid:1.3.6.1.4.1.5923.1.1.1.1' => array('member','student'),
> ),
> 51 => array(
> 'class' => 'core:AttributeMap',
> 'sAMAccountName' => 'urn:oid:0.9.2342.19200300.100.1.1',
> 'userPrincipalName' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
> ),
> 52 => array(
> 'class' => 'core:ScopeAttribute',
> 'scopeAttribute' => 'eduPersonScopedAffiliation',
> 'sourceAttribute' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
> 'targetAttribute' => 'eduPersonPrincipalName',
> ),
> // Convert LDAP names to oids.
> 30 => array('class' => 'core:AttributeMap', 'name2oid'),
userPrincipalName, see one of my previous mails about that.
2. Not sure about your use and mixture of basic names
("sAMAccountName") and OID-based URN names in the same config.
Why specifically are you doing that?
I'd use basic names throughout the config and only convert them to
oids at the end (your number 30). So keep the names basic and move the
name2oid map to run after all the others, at least for sanity.
> Anyone see why urn:oid:1.3.6.1.4.1.5923.1.1.1.6 which I have to map
> to 'userPrincipalName since that is what contains our users emails
> in ldap isn't still getting scoped.
long as you're only sending the OID-based URN (and with the correct
nameFormat) the friendlyName doesn't matter.
Also, "urn:oid:1.3.6.1.4.1.5923.1.1.1.6" is not defined to be the
subject's email address, though you can choose to implement it that
way (i.e, it's syntactically equivalent, though not semantically).
If you want to send the subject's email address why not issue the
attribute "urn:oid:0.9.2342.19200300.100.1.3" (mail) instead?
Also, what do you actually send in the assertion? Hard to say what's
wrong without seeing what actually goes out.
> For some reason it says eduPersonScopedAffiliation isn't scoped
> either.
You could grab it from your logs (on debug), or, in case the assertion
is not encrypted, from the browser, e.g. using the SAMLtracer plugin
for Mozilla Firefox.
> Even though it should be by default. I have to convert to oid's
> since that is what the SP uses.
their specification for usage in SAML,
http://macedir.org/docs/internet2-mace-dir-saml-attributes-latest.pdf
-peter
weisman491
Nov 13, 2014, 10:19:17 AM11/13/14
to simple...@googlegroups.com
This is what is in the last log I sent, the reason I map to userPrincipalName and so on is the SP only looks for the oid and for specific ones. Anything not the exact oid they want gets skipped over.
This is what was passed
Not sure why the highlighted happened, I guess that was from the mapping. The names arn't getting changed to oid's anymore either. Should I move the priority of this up higher in the authproc for that to happen correctly, that way I can stick to friendlynames and convert:
<saml:Attribute Name="eduPersonScopedAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string">uni.edu</saml:AttributeValue><saml:AttributeValue xsi:type="xs:string">sub.uni.edu</saml:AttributeValue></saml:Attribute><saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string">member</saml:AttributeValue><saml:AttributeValue xsi:type="xs:string">student</saml:AttributeValue></saml:Attribute><saml:Attribute Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string">tsw003</saml:AttributeValue></saml:Attribute><saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string">exa...@sub.uni.edu</saml:AttributeValue></saml:Attribute><saml:Attribute Name="eduPersonPrincipalName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string">exa...@sub.uni.edu@uni.edu</saml:AttributeValue><saml:AttributeValue xsi:type="xs:string">exa...@sub.uni.edu@sub.uni.edu</saml:AttributeValue></saml:Attribute>
Not sure why the highlighted happened, I guess that was from the mapping. The names arn't getting changed to oid's anymore either. Should I move the priority of this up higher in the authproc for that to happen correctly, that way I can stick to friendlynames and convert:
30 => array('class' => 'core:AttributeMap', 'name2oid'),
),
Then this is the warnings after it trys to get the metadata
2014-11-13 09:59:47 DEBUG Shibboleth.AttributeExtractor.XML [54]: skipping unmapped NameID with format (urn:oasis:names:tc:SAML:2.0:nameid-format:transient)
2014-11-13 09:59:47 DEBUG Shibboleth.AttributeExtractor.XML [54]: unable to extract attributes, unknown XML object type: saml:AuthnStatement
2014-11-13 09:59:47 INFO Shibboleth.AttributeExtractor.XML [54]: skipping unmapped SAML 2.0 Attribute with Name: eduPersonScopedAffiliation
2014-11-13 09:59:47 DEBUG Shibboleth.AttributeDecoder.String [54]: decoding SimpleAttribute (unscoped-affiliation) from SAML 2 Attribute (urn:oid:1.3.6.1.4.1.5923.1.1.1.1) with 2 value(s)
2014-11-13 09:59:47 DEBUG Shibboleth.AttributeDecoder.String [54]: decoding SimpleAttribute (uid) from SAML 2 Attribute (urn:oid:0.9.2342.19200300.100.1.1) with 1 value(s)
2014-11-13 09:59:47 DEBUG Shibboleth.AttributeDecoder.Scoped [54]: decoding ScopedAttribute (eppn) from SAML 2 Attribute (urn:oid:1.3.6.1.4.1.5923.1.1.1.6) with 1 value(s)
2014-11-13 09:59:47 INFO Shibboleth.AttributeExtractor.XML [54]: skipping unmapped SAML 2.0 Attribute with Name: eduPersonPrincipalName
2014-11-13 09:59:47 DEBUG Shibboleth.AttributeFilter [54]: filtering 3 attribute(s) from (example)
2014-11-13 09:59:47 DEBUG Shibboleth.AttributeFilter [54]: applying filtering rule(s) for attribute (eppn) from (example)
2014-11-13 09:59:47 WARN Shibboleth.AttributeFilter [54]: removed value at position (0) of attribute (eppn) from (example)
2014-11-13 09:59:47 DEBUG Shibboleth.AttributeFilter [54]: applying filtering rule(s) for attribute (uid) from (example)
2014-11-13 09:59:47 DEBUG Shibboleth.AttributeFilter [54]: applying filtering rule(s) for attribute (unscoped-affiliation) from (example)
2014-11-13 09:59:47 WARN Shibboleth.AttributeFilter [54]: no values left, removing attribute (eppn) from (example)
2014-11-13 09:59:47 DEBUG Shibboleth.SSO.SAML2 [54]: resolving attributes...
weisman491
Nov 13, 2014, 10:35:03 AM11/13/14
to simple...@googlegroups.com
Ignore my last post, I think it would be best to go at this one step at a time. So lets make it simple. This passed correctly, but the SP filtered out the attributes with the following error. This is in my saml20-sp-remote on my IDP for the SP we're trying to connect with.
'authproc' => array(
90 => array('class' => 'core:AttributeMap', 'name2oid'),
60 => array(
'class' => 'core:AttributeAdd',
'eduPersonScopedAffiliation' => array('mem...@uni.edu','mem...@sub.uni.edu'),
),
),
The SP logs:
//This worked and passed like I wanted now. they are looking for mem...@myuni.edu for the scope apprently
<saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xs:string">mem...@uni.edu</saml:AttributeValue><saml:AttributeValue xsi:type="xs:string">mem...@uni.edu</saml:AttributeValue></saml:Attribute>
2014-11-13 10:24:58 DEBUG Shibboleth.AttributeDecoder.Scoped [57]: decoding ScopedAttribute (affiliation) from SAML 2 Attribute (urn:oid:1.3.6.1.4.1.5923.1.1.1.9) with 2 value(s)
2014-11-13 10:24:58 DEBUG Shibboleth.AttributeFilter [57]: filtering 1 attribute(s) from ()
2014-11-13 10:24:58 DEBUG Shibboleth.AttributeFilter [57]: applying filtering rule(s) for attribute (affiliation) from ()
2014-11-13 10:24:58 WARN Shibboleth.AttributeFilter [57]: removed value at position (0) of attribute (affiliation) from ()
2014-11-13 10:24:58 WARN Shibboleth.AttributeFilter [57]: removed value at position (1) of attribute (affiliation) from ()
Just have to figure out why this was removed.
Peter Schober
Nov 13, 2014, 10:39:16 AM11/13/14
to simple...@googlegroups.com
* weisman491 <weism...@gmail.com> [2014-11-13 16:19]:
needlessly confusing yourself by calling what is defined to be the
SAML2.0 URI name of the eduPersonPrincipalName attribute the
"userPrincipalName".
> <saml:Attribute Name="eduPersonScopedAffiliation"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">uni.edu</saml:AttributeValue><saml:AttributeValue
> xsi:type="xs:string">sub.uni.edu</saml:AttributeValue></saml:Attribute>
This is wrong. The XML-attribute 'Name' needs to be the URI for ePSA,
i.e. "urn:oid:1.3.6.1.4.1.5923.1.1.1.9", for one because the MACE-Dir
SAML specs defined it that way, but also because you're saying the
Name is a URI here (in the NameFormat XML-attribute), when clearly
"eduPersonScopedAffiliation" is not a valid URI.
The AttributeValue elements are OK.
> <saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">member</saml:AttributeValue><saml:AttributeValue
> xsi:type="xs:string">student</saml:AttributeValue></saml:Attribute>
That is OK and your scoped affiliations should be sent just you're
already sending the unscoped ones.
> <saml:Attribute
> Name="urn:oid:0.9.2342.19200300.100.1.1"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">tsw003</saml:AttributeValue></saml:Attribute>
That's also OK, though sendung the userid/uid often doesn't make much
sense in federated deployments, i.e., where the SP is not from the
same organization as the IDP, since userid/uid is not defined to be
globally unique by itself.
> <saml:Attribute
> Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">exa...@sub.uni.edu</saml:AttributeValue></saml:Attribute>
Your eduPersonPrincipalName (short ePPN; which is what
"urn:oid:1.3.6.1.4.1.5923.1.1.1.6" means) is also correct on the wire.
> <saml:Attribute
> Name="eduPersonPrincipalName"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">exa...@sub.uni.edu@uni.edu</saml:AttributeValue><saml:AttributeValue
> xsi:type="xs:string">exa...@sub.uni.edu@sub.uni.edu</saml:AttributeValue></saml:Attribute>
You already sent ePPN correctly above, now you're sending again
incorrectly. See the explanation above for the incorrect version of
your eduPersonScopedAffiliation ('Name' is wrong and matches neither
the spec nor the stated NameFormat).
And the values are wrong too, of course.
> Not sure why the highlighted happened, I guess that was from the
> mapping.
Seems you've managed confused yourself on several levels, you've added
a scope to an attribut that's already scoped.
> The names arn't getting changed to oid's anymore either. Should I move the
> priority of this up higher in the authproc for that to happen correctly,
> that way I can stick to friendlynames and convert:
> 30 => array('class' => 'core:AttributeMap', 'name2oid'),
>
> ),
Not sure that that means. I already told you to remove all the OIDs
from the authproc filter and only invoke the name2oid map after you've
created all the attributes to your liking.
> Then this is the warnings after it trys to get the metadata
value that's defined for ePSA.
> 2014-11-13 09:59:47 DEBUG Shibboleth.AttributeDecoder.String [54]:
> decoding SimpleAttribute (unscoped-affiliation) from SAML 2
> Attribute (urn:oid:1.3.6.1.4.1.5923.1.1.1.1) with 2 value(s)
That went well, ilke I said above it would.
> 2014-11-13 09:59:47 DEBUG Shibboleth.AttributeDecoder.String [54]:
> decoding SimpleAttribute (uid) from SAML 2 Attribute
> (urn:oid:0.9.2342.19200300.100.1.1) with 1 value(s)
Same here.
> 2014-11-13 09:59:47 DEBUG Shibboleth.AttributeDecoder.Scoped [54]:
> decoding ScopedAttribute (eppn) from SAML 2 Attribute
> (urn:oid:1.3.6.1.4.1.5923.1.1.1.6) with 1 value(s)
And again.
> 2014-11-13 09:59:47 INFO
> Shibboleth.AttributeExtractor.XML [54]: skipping unmapped SAML 2.0
> Attribute with Name: eduPersonPrincipalName
Same mistake as for ePSA.
> 2014-11-13 09:59:47 DEBUG Shibboleth.AttributeFilter [54]: applying
> filtering rule(s) for attribute (uid) from (example)
> 2014-11-13 09:59:47 DEBUG Shibboleth.AttributeFilter [54]: applying
> filtering rule(s) for attribute (unscoped-affiliation) from (
> example)
These are ok.
> 2014-11-13 09:59:47 WARN Shibboleth.AttributeFilter [54]:
> no values left, removing attribute (eppn) from (example)
This one's gone.
All the info you might need is there for you, in that log from a
non-SimpleSAMLphp software.
-peter
> the reason I map to userPrincipalName and so on is the SP only looks
> for the oid and for specific ones. Anything not the exact oid they
> want gets skipped over.
You can call it what you want internally. I'm just saying that you're
> for the oid and for specific ones. Anything not the exact oid they
> want gets skipped over.
needlessly confusing yourself by calling what is defined to be the
SAML2.0 URI name of the eduPersonPrincipalName attribute the
"userPrincipalName".
> <saml:Attribute Name="eduPersonScopedAffiliation"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">uni.edu</saml:AttributeValue><saml:AttributeValue
> xsi:type="xs:string">sub.uni.edu</saml:AttributeValue></saml:Attribute>
i.e. "urn:oid:1.3.6.1.4.1.5923.1.1.1.9", for one because the MACE-Dir
SAML specs defined it that way, but also because you're saying the
Name is a URI here (in the NameFormat XML-attribute), when clearly
"eduPersonScopedAffiliation" is not a valid URI.
The AttributeValue elements are OK.
> <saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">member</saml:AttributeValue><saml:AttributeValue
> xsi:type="xs:string">student</saml:AttributeValue></saml:Attribute>
already sending the unscoped ones.
> <saml:Attribute
> Name="urn:oid:0.9.2342.19200300.100.1.1"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">tsw003</saml:AttributeValue></saml:Attribute>
sense in federated deployments, i.e., where the SP is not from the
same organization as the IDP, since userid/uid is not defined to be
globally unique by itself.
> <saml:Attribute
> Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">exa...@sub.uni.edu</saml:AttributeValue></saml:Attribute>
"urn:oid:1.3.6.1.4.1.5923.1.1.1.6" means) is also correct on the wire.
> <saml:Attribute
> Name="eduPersonPrincipalName"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">exa...@sub.uni.edu@uni.edu</saml:AttributeValue><saml:AttributeValue
> xsi:type="xs:string">exa...@sub.uni.edu@sub.uni.edu</saml:AttributeValue></saml:Attribute>
incorrectly. See the explanation above for the incorrect version of
your eduPersonScopedAffiliation ('Name' is wrong and matches neither
the spec nor the stated NameFormat).
And the values are wrong too, of course.
> Not sure why the highlighted happened, I guess that was from the
> mapping.
a scope to an attribut that's already scoped.
> The names arn't getting changed to oid's anymore either. Should I move the
> priority of this up higher in the authproc for that to happen correctly,
> that way I can stick to friendlynames and convert:
> 30 => array('class' => 'core:AttributeMap', 'name2oid'),
>
> ),
from the authproc filter and only invoke the name2oid map after you've
created all the attributes to your liking.
> Then this is the warnings after it trys to get the metadata
> 2014-11-13 09:59:47 INFO Shibboleth.AttributeExtractor.XML [54]:
> skipping unmapped SAML 2.0 Attribute with Name:
> eduPersonScopedAffiliation
Yes, just what I said above. The name needs to be the OID-based URN
> skipping unmapped SAML 2.0 Attribute with Name:
> eduPersonScopedAffiliation
value that's defined for ePSA.
> 2014-11-13 09:59:47 DEBUG Shibboleth.AttributeDecoder.String [54]:
> decoding SimpleAttribute (unscoped-affiliation) from SAML 2
> Attribute (urn:oid:1.3.6.1.4.1.5923.1.1.1.1) with 2 value(s)
> 2014-11-13 09:59:47 DEBUG Shibboleth.AttributeDecoder.String [54]:
> decoding SimpleAttribute (uid) from SAML 2 Attribute
> (urn:oid:0.9.2342.19200300.100.1.1) with 1 value(s)
> 2014-11-13 09:59:47 DEBUG Shibboleth.AttributeDecoder.Scoped [54]:
> decoding ScopedAttribute (eppn) from SAML 2 Attribute
> (urn:oid:1.3.6.1.4.1.5923.1.1.1.6) with 1 value(s)
> 2014-11-13 09:59:47 INFO
> Shibboleth.AttributeExtractor.XML [54]: skipping unmapped SAML 2.0
> Attribute with Name: eduPersonPrincipalName
> 2014-11-13 09:59:47 DEBUG Shibboleth.AttributeFilter [54]: applying
> filtering rule(s) for attribute (uid) from (example)
> 2014-11-13 09:59:47 DEBUG Shibboleth.AttributeFilter [54]: applying
> filtering rule(s) for attribute (unscoped-affiliation) from (
> example)
> 2014-11-13 09:59:47 WARN Shibboleth.AttributeFilter [54]:
> no values left, removing attribute (eppn) from (example)
All the info you might need is there for you, in that log from a
non-SimpleSAMLphp software.
-peter
Peter Schober
Nov 13, 2014, 10:43:33 AM11/13/14
to simple...@googlegroups.com
* weisman491 <weism...@gmail.com> [2014-11-13 16:35]:
spec (SAML attribute profiles).
So the only reason I can think of for the SP to throw away those
values is what you allude to above yourself:
If the SAML metadata for your own IDP says "uni.edu" is an allowed
Scope, and that same IDP is sending scoped attributes with a different
scope ("myuni.edu") then that SP has every right to remove those
values.
So what Scope does your own IDP advertize in SAML metadata?
It's your choice what to put there.
It's also your choice what scopes to send in SAML attributes.
But those two should match, or SPs will filter out offending values,
which is the /whole/ purpose of scoped attributes!
-peter
> The SP logs:
> //This worked and passed like I wanted now. they are looking for
> mem...@myuni.edu for the scope apprently
>
> <saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">mem...@uni.edu</saml:AttributeValue><saml:AttributeValue
> xsi:type="xs:string">mem...@uni.edu</saml:AttributeValue></saml:Attribute>
That's syntactically corrent and also conforming to the eduPerson
> //This worked and passed like I wanted now. they are looking for
> mem...@myuni.edu for the scope apprently
>
> <saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
> xsi:type="xs:string">mem...@uni.edu</saml:AttributeValue><saml:AttributeValue
> xsi:type="xs:string">mem...@uni.edu</saml:AttributeValue></saml:Attribute>
spec (SAML attribute profiles).
So the only reason I can think of for the SP to throw away those
values is what you allude to above yourself:
If the SAML metadata for your own IDP says "uni.edu" is an allowed
Scope, and that same IDP is sending scoped attributes with a different
scope ("myuni.edu") then that SP has every right to remove those
values.
So what Scope does your own IDP advertize in SAML metadata?
It's your choice what to put there.
It's also your choice what scopes to send in SAML attributes.
But those two should match, or SPs will filter out offending values,
which is the /whole/ purpose of scoped attributes!
-peter
weisman491
Nov 13, 2014, 10:48:22 AM11/13/14
to simple...@googlegroups.com, peter....@univie.ac.at
Sorry for the confusion I was just typing those in, the values match, it is supposed to be mem...@bridgewater.edu I was just using examples. At this point it doesn't really matter to hide it in the posts. This is what the SP is looking for. Yet it filters them out anyway. This is where the confusion is coming from. We've used these scopes in the past fine with other SP's. No issues, but this one in particular just rejects it every time and they swear to me they are looking for scope = mem...@bridgewater.edu. I've basically just hit a dead end.
> xsi:type="xs:string">example@sub.uni.edu@uni.edu</saml:AttributeValue><saml:AttributeValue
> xsi:type="xs:string">example@sub.uni.edu@sub.uni.edu</saml:AttributeValue></saml:Attribute>
weisman491
Nov 13, 2014, 11:25:51 AM11/13/14
to simple...@googlegroups.com, peter....@univie.ac.at
Update, issue has been resolved.
The problem was the saml20-idp-hosted metadata. I wasn't aware you had to have these lines in it for the stuff I was placing in my sp-remote to work correctly.
'scope'=>array('bridgewater.edu'),
'scopedattributes'=>array('eduPersonScopedAffiliation'),
This may be helpful if an example and some info is written about this in the documentation on https://simplesamlphp.org/docs/stable/simplesamlphp-reference-idp-hosted
Currently it only mentions "scope" and even then that didn't tell me very much. I've spent a week on this issue not even realizing this was required for the scope to function.
I want to thank you guys for your emails and support it was a big help.
Tyler
Peter Schober
Nov 13, 2014, 2:49:59 PM11/13/14
to simple...@googlegroups.com
* weisman491 <weism...@gmail.com> [2014-11-13 17:25]:
irrelevant for what the SP sees, unless the SP is pulling metadata
from your IDP directly (with all the trust problems some of which Tom
and I have already tried to explain). If the SP is part of InCommon
(like your IDP) what your SSP system auto-generates is positvely
irrelevant.
And "scopedattributes" is listed under "Shibboleth 1.3 options" and
will only influence the XML structure used for Scoped affiliations
(carrying the "Scope" in an extra XML attribute on the AttributeValue
XML element).
That format was given up on years ago, precisely so because hardly any
SAML implementation could access the seperately transmitted scope.
Hence the newer (and more interoperable) default of having the scope
part of the string value.
In any case, the logs you posted where from a recent Shibboleth 2.x
SP, which absolutely can handle both the old and the new form.
(I'm not even aware how you would configure that software to only
accept the old/obsolete syntax for this.)
TL;DR: Whatever you may think these two things magically did, they did
not make this work. Both the XML from the SAML assertion *and* logs
from the SP were clear that the attribute names were wrong.
I gave you detailed explanations what was wrong *and* *why* in every
single case/for every single attribute.
the above change in your saml20-idp-hosted.php did nothing to fix that.
-peter
> Update, issue has been resolved.
> The problem was the saml20-idp-hosted metadata. I wasn't aware you had to
> have these lines in it for the stuff I was placing in my sp-remote to work
> correctly.
> 'scope'=>array('bridgewater.edu'),
> 'scopedattributes'=>array('eduPersonScopedAffiliation'),
[...]
> The problem was the saml20-idp-hosted metadata. I wasn't aware you had to
> have these lines in it for the stuff I was placing in my sp-remote to work
> correctly.
> 'scope'=>array('bridgewater.edu'),
> 'scopedattributes'=>array('eduPersonScopedAffiliation'),
> on https://simplesamlphp.org/docs/stable/simplesamlphp-reference-idp-hosted
> Currently it only mentions "scope" and even then that didn't tell me very
> much. I've spent a week on this issue not even realizing this was required
> for the scope to function.
No. "scope" only influences the auto-generated SAML metadata, which is
> Currently it only mentions "scope" and even then that didn't tell me very
> much. I've spent a week on this issue not even realizing this was required
> for the scope to function.
irrelevant for what the SP sees, unless the SP is pulling metadata
from your IDP directly (with all the trust problems some of which Tom
and I have already tried to explain). If the SP is part of InCommon
(like your IDP) what your SSP system auto-generates is positvely
irrelevant.
And "scopedattributes" is listed under "Shibboleth 1.3 options" and
will only influence the XML structure used for Scoped affiliations
(carrying the "Scope" in an extra XML attribute on the AttributeValue
XML element).
That format was given up on years ago, precisely so because hardly any
SAML implementation could access the seperately transmitted scope.
Hence the newer (and more interoperable) default of having the scope
part of the string value.
In any case, the logs you posted where from a recent Shibboleth 2.x
SP, which absolutely can handle both the old and the new form.
(I'm not even aware how you would configure that software to only
accept the old/obsolete syntax for this.)
TL;DR: Whatever you may think these two things magically did, they did
not make this work. Both the XML from the SAML assertion *and* logs
from the SP were clear that the attribute names were wrong.
I gave you detailed explanations what was wrong *and* *why* in every
single case/for every single attribute.
the above change in your saml20-idp-hosted.php did nothing to fix that.
-peter
Tyler Weisman
Nov 13, 2014, 4:42:54 PM11/13/14
to simple...@googlegroups.com
All I know is our connection is working perfectly after adding this to the saml20-sp-remote.php under the SP's metadata
'authproc' => array(
90 => array('class' => 'core:AttributeMap', 'name2oid'),
60 => array(
'class' => 'core:AttributeAdd',and this to the saml20-idp-hosted.php
'scope'=>array('bridgewater.edu'),
'scopedattributes'=>array('eduPersonScopedAffiliation'),
'scopedattributes'=>array('eduPersonScopedAffiliation'),
If I take either one of these out of the idp hosted or sp-remote we get the same error as before. It could be possible something with the way the SP is looking for this data (which I have little background in to even understand it) could have caused the need for this to be set up the way it is.
As I said the issue is resolved and I thank you guys for the support. I've been trying to understand everything you we're trying to explain with why those attributes we're wrong. However some of it just went over my head. I am still fairly new to SSO.
Also my reasoning behind why I believe something could be configured badly on the SP is this all started when they upgraded their system from shib 1.0. The guys working on it we're newer to it as well and told me they just "copied" their old set up and config files to the new one. It was after this upgrade our old metadata in our shib13-sp-remote.php obviously stopped working and we had to update our metadata. Figured a little background might help things make a little more sense?
-peter
--
You received this message because you are subscribed to a topic in the Google Groups "simpleSAMLphp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/simplesamlphp/KEqpHn1gdoc/unsubscribe.
To unsubscribe from this group and all its topics, 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.
Reply all
Reply to author
Forward
0 new messages