Experience with OIDC plugin

[Janne Lauros]

Hi!


         <PolicyRequirementRule xsi:type="AND">
            <Rule xsi:type="Requester" value="urizen" />
            <Rule xsi:type="oidcext:OIDCScope" value="edumember_is_member_of" />
         </PolicyRequirementRule>

Just a note..for a claim/attribute to pass "oidcext:OIDCScope" two things are needed. 1) rp needs to request for the scope and 2) rp needs to have that scope listed in it's registration data. The rule for "Requester" is not needed if registration data already defines who are allowed to ask for which scopes.



         Shib's audit log shows it being released on all requests.  However, the atribute never appears in the OIDC response

With code flow these attributes should come by default in UserInfo response, they will not be in Id Token unless explicitly instructed to (encoder option). Now, if you are not receiving them in UserInfo response there are two possibilities. 1) You do not have OIDC Encoder for the attribute and thus it cannot be encoded or the more complex one or 2) You have a scripted attribute that relies on information available only in front channel (this too can be tackled with encoder option). 

See https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/AttributeEncoderPluginConfiguration

If none of the above applies and/or you are still not receiving the attributes in response, I can take a look at the logs.

 BR Janne



----- Original Message -----
From: "Jim Fox" <fox at washington.edu>
To: "Janne Lauros" <janne.lauros at csc.fi>
Cc: "dev" <dev at shibboleth.net>
Sent: Monday, 19 November, 2018 20:55:27
Subject: Re: Experience with OIDC plugin

>>
>> The attribute filtering behaviour the way you describe it, that should not happen. Could you send me a full log (<logger name="fi.csc" level="ALL"/>) of the event with your attribute filter and resolver files.
>>
>

Sorry, I seem to have gotten confused on Friday.  Attribute filtering is 
working as it should.   Rules by scope alone seem to work.  I do not need the SP-specific rules.

Except I did use it this way:

     <AttributeFilterPolicy id="OPENID_MEMBER_OF">
         <PolicyRequirementRule xsi:type="AND">
            <Rule xsi:type="Requester" value="urizen" />
            <Rule xsi:type="oidcext:OIDCScope" value="edumember_is_member_of" />
         </PolicyRequirementRule>
         <AttributeRule attributeID="gws_groups">
            <PermitValueRule xsi:type="basic:OR">
             <basic:Rule xsi:type="basic:AttributeValueString" value="urn:mace:washington.edu:groups:u_fox_00-spud99"/>
             <basic:Rule xsi:type="basic:AttributeValueString" value="urn:mace:washington.edu:groups:uw_employee"/>
             <basic:Rule xsi:type="basic:AttributeValueString" value="urn:mace:washington.edu:groups:uw_member"/>
             <basic:Rule xsi:type="basic:AttributeValueString" value="urn:mace:washington.edu:groups:uw_staff"/>
             <basic:Rule xsi:type="basic:AttributeValueRegex" regex="urn:mace:washington.edu:groups:u_fox_brow.*"/>
            </PermitValueRule>
         </AttributeRule>
     </AttributeFilterPolicy>


Which is how we could filter memberof attributes by SP.


I also tried to add an attribute to the 'profile' scope,

     <AttributeFilterPolicy id="OPENID_SCOPE_PROFILE">
         <PolicyRequirementRule xsi:type="oidcext:OIDCScope" value="profile" />
         <AttributeRule attributeID="name">
             <PermitValueRule xsi:type="ANY" />
         </AttributeRule>
         <AttributeRule attributeID="preferredFirst">
             <PermitValueRule xsi:type="ANY" />
         </AttributeRule>
         ...


Shib's audit log shows it being released on all requests.  However, the atribute never appears in the OIDC response.  It does appear in one place in the geant debug log:

   Profile Action ValidateGrant: authz code unwrapped {"sub":"fox","cnsntd_claims":["displayName"... "preferredFirst" ...

but is seems to otherwise ignored.

Is the 'profile' set of attributes fixed?

Jim