subject-id as a computedID help

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

subject-id as a computedID help

Satya Mohapatra
Hi,

I am trying to implement the new subject-id as a computedID.

Here is the relevant snippet from attribute-resolver.xml of the IdP.

        <!-- Deprecated persistent NameID wrapped in a deprecated SAML Attribute value -->
    <resolver:AttributeDefinition id="subject-id" xsi:type="ad:Scoped" scope=“test.org" sourceAttributeID="computedID">
      <resolver:Dependency ref="computedID" />
      <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString" name="urn:oasis:names:tc:SAML:attribute:subject-id" friendlyName="subject-id" encodeType="false" />
    </resolver:AttributeDefinition>

   <resolver:DataConnector id="computedID" xsi:type="ComputedId" xmlns="urn:mace:shibboleth:2.0:resolver:dc" generatedAttributeID="computedID" sourceAttributeID="employeeNumber" salt="%{idp.persistentId.salt}">
      <resolver:Dependency ref=“LDAP" />
    </resolver:DataConnector>



At the SP,  I am seeing the attribute is being removed.

WARN Shibboleth.AttributeFilter [1] [default]: removed value at position (0) of attribute (subject-id) from (https://login-test.ligo.org/idp/shibboleth)
WARN Shibboleth.AttributeFilter [1] [default]: no values left, removing attribute (subject-id) from (https://login-test.ligo.org/idp/shibboleth)


The attribute map at the SP has the following:
 <Attribute name="urn:oasis:names:tc:SAML:attribute:subject-id" id="subject-id”/>



Any suggestion what I could be doing wrong ?


Thanks,
---
Satya Mohapatra | ସତ୍ୟ ମହାପାତ୍ର |  सत्य महापात्र |  ستیا موہپترا



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

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: subject-id as a computedID help

Cantor, Scott E.
On 1/15/20, 11:14 PM, "users on behalf of Satya Mohapatra" <[hidden email] on behalf of [hidden email]> wrote:
> Any suggestion what I could be doing wrong ?

Probably not including test.org in a Scope extension in the IdP's metadata.

-- Scott


--
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: subject-id as a computedID help

Satya Mohapatra
Hi Alan, Scott, 

Thanks for both of your responses which indeed helped me debug the problem.  It turned out at the SP attribute-policy.xml the scope filtering was the cause. 

The relevant section of attribute-policy.xml of the SP.


<afp:PermitValueRule id="ScopingRules" xsi:type="AND">
        <Rule xsi:type="NOT">
            <Rule xsi:type="AttributeValueRegex" regex="@"/>
</Rule>
        <Rule xsi:type="saml:AttributeScopeMatchesShibMDScope"/>
    </afp:PermitValueRule>

 <afp:AttributeRule attributeID="subject-id"> -->
        <!--     <afp:PermitValueRuleReference ref="ScopingRules"/> —>
  <!-- </afp:AttributeRule> -->

When I comment out to drop scope checking rule for "subject-id” then I get the attribute all right. 

Please note that the “test.org” in my earlier email was just a mistaken entry in the email. When I actually use the correct scope string or even %{idp.scope}, the above attribute-policy at the SP is dropping the attribute. 

<resolver:AttributeDefinition id="subject-id" xsi:type="ad:Scoped" scope=“%{idp.scope}" sourceAttributeID="computedID">
     <resolver:Dependency ref="computedID" />
     <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString" name="urn:oasis:names:tc:SAML:attribute:subject-id" friendlyName="subject-id" encodeType="false" />
   </resolver:AttributeDefinition>


Thanks, 


---
Satya Mohapatra | ସତ୍ୟ ମହାପାତ୍ର |  सत्य महापात्र |  ستیا موہپترا


On Jan 16, 2020, at 9:09 AM, Cantor, Scott <[hidden email]> wrote:

On 1/15/20, 11:14 PM, "users on behalf of Satya Mohapatra" <[hidden email] on behalf of [hidden email]> wrote:
Any suggestion what I could be doing wrong ?

Probably not including test.org in a Scope extension in the IdP's metadata.

Scott


On Jan 16, 2020, at 5:24 AM, Alan Buxey <[hidden email]> wrote:
hi,

WARN Shibboleth.AttributeFilter [1] [default]: removed value at position (0) of attribute (subject-id) from (https://login-test.ligo.org/idp/shibboleth)
WARN Shibboleth.AttributeFilter [1] [default]: no values left, removing attribute (subject-id) from (https://login-test.ligo.org/idp/shibboleth)

is that ALL its saying? no mention above that top line about applying
filtering rule?

The attribute map at the SP has the following:
<Attribute name="urn:oasis:names:tc:SAML:attribute:subject-id" id="subject-id”/>


is that all?  no attribute decoder specified?


I would run a login session with SAMLTracer plugin being used so you
can see what messages and values are being sent through (format etc).

alan






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

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: subject-id as a computedID help

Cantor, Scott E.
On 1/16/20, 11:11 AM, "users on behalf of Satya Mohapatra" <[hidden email] on behalf of [hidden email]> wrote:

> When I comment out to drop scope checking rule for "subject-id” then I get the attribute all right.

Then you know the cause.

> When I actually use the correct scope string or even %{idp.scope}, the above attribute-policy at the SP is dropping the
> attribute.

And that means the metadata doesn't match.

-- Scott


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