requesting specific claims from the OIDC provider

[Wessel, Keith]

It definitely still works, Janne. We have several sites and applications using it in production.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Janne Lauros
Sent: Tuesday, October 13, 2020 4:52 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: requesting specific claims from the OIDC provider

Hi!

 In addition to what Keith replied, snippet from example filter coming with the extension:

     <AttributeFilterPolicy id="REQUESTED_CLAIMS">
        <PolicyRequirementRule xsi:type="ANY" />
        <!-- Release picture if asked to be released -->
        <AttributeRule attributeID="picture">
            <PermitValueRule xsi:type="oidcext:AttributeInOIDCRequestedClaims" />
        </AttributeRule>
        <!-- Release email in id token if specifically asked to be released for id token -->
        <AttributeRule attributeID="email_idtoken">
            <PermitValueRule xsi:type="oidcext:AttributeInOIDCRequestedClaims" matchOnlyIDToken="true" />
        </AttributeRule>
        <!-- Release email if specifically asked to be released for userinfo. -->
        <AttributeRule attributeID="email">
            <PermitValueRule xsi:type="oidcext:AttributeInOIDCRequestedClaims" matchOnlyUserInfo="true" />
        </AttributeRule>
        <!-- Release name if specifically asked to be released for userinfo and flagged as essential -->
        <AttributeRule attributeID="name">
            <PermitValueRule xsi:type="oidcext:AttributeInOIDCRequestedClaims" matchOnlyUserInfo="true"
                onlyIfEssential="true" />
        </AttributeRule>
    </AttributeFilterPolicy>

  So there is small granularity when doing the filtering per requested attributes. This worked last time I checked but that is something like a year ago ;-). Just remember this is different from SAML2 Requested Attributes as we have no inbuilt mechanism for expressing what the client is allowed to request.

 BR Janne  

----- Original Message -----
From: "Wessel, Keith" <kwessel at illinois.edu>
To: "Shib Users" <users at shibboleth.net>
Sent: Monday, 12 October, 2020 22:16:10
Subject: RE: requesting specific claims from the OIDC provider



Liam, 



Did you tell the attribute filter configuration to release said claims if requested? 



<PermitValueRule xsi:type="oidcext:AttributeInOIDCRequestedClaims" /> 



I have an attribute filter policy that has a policy requirement rule of all users who aren’t FERPA suppressed. Inside there, I have attribute rules for all attributes that I want to make available upon request that have that permit matcher rule on them. 



Keith 




From: users <users-bounces at shibboleth.net> On Behalf Of Liam Hoekenga 
Sent: Monday, October 12, 2020 2:06 PM 
To: Shib Users <users at shibboleth.net> 
Subject: requesting specific claims from the OIDC provider 





Most of the time that I have added additional claims to our IDP (e.g. "eduperson_principal_name"), I've also created custom scopes named after the LDAP schemas (e.g. "eduperson") and tied the claim to that scope. 





I'm trying to configure the release for an institutionally specific attribute and we haven't really considered any scopes for institutional claims (umich* attributes). 





I'm trying to request claims using the claims parameter, and I don't seem to be having much luck. 


A previous thread suggests that it's possible.. 


[ https://marc.info/?l=shibboleth-users&m=159164654427455&w=2 | https://marc.info/?l=shibboleth-users&m=159164654427455&w=2 ] 





I'm using mod_auth_openidc, and have tried both of the's claim requests (URL encoded of course): 


{"id_token":{"email":null,"email_verified":null},"userinfo":{"email":null,"email_verified":null,"name":null}} 





{"id_token":{"email":{"essential":true},"email_verified":{"essential":true}},"userinfo":{"email":{"essential":true},"email_verified":{"essential":true},"name":{"essential":true}}} 





Any suggestions? 





Liam 

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

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