Experience with OIDC plugin

[Janne Lauros]

Hi Jim,

 First about the session storage. When accessing UserInfo endpoint OIDC expects for OP to verify user presence unless request has offline_access scope. The extension does it by verifying user session still exists. This is of course possible only with server side session storage. At minimum this needs to be instructed better. If having server side session storage (or using offline_access scope value) are not feasible we may have to find a better solution.

 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.  


 Br Janne



----- Original Message -----
From: "Jim Fox" <fox at washington.edu>
To: "dev" <dev at shibboleth.net>
Sent: Friday, 16 November, 2018 23:55:42
Subject: Experience with OIDC plugin

( summarized repost from the shib users list )

This is a first look at the beta oidc extension.

The instructions were easy to follow.

One thing regarding the issuer setting in idp-oidc.properties:  Instructions say it has to be https scheme, host, .. However, my dev idp has an
entity id of "urn:mace:incommon:washington.edu:dev".  This seemd to work ok.

Shib default (I think) is cookie sessions.  The extension requires memory (1 host) or some sort of shared, server-side session.  Don't know how easy t
hat'll be for most sites.

Attribute filtering seems a bit sketchy.

If I set this

     <AttributeFilterPolicy id="OPENID_SCOPE_EMAIL">
         <PolicyRequirementRule xsi:type="oidcext:OIDCScope" value="email" />
         <AttributeRule attributeID="email">
             <PermitValueRule xsi:type="ANY" />
         </AttributeRule>
     </AttributeFilterPolicy>

I see email being released on the initial login (shows in the audit log), however when the SP hits the userinfo endpoint email is not released. To
get email released at userinfo I also need this filter policy

     <AttributeFilterPolicy id="OPENID_urizen">
         PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urizen"/>
         <AttributeRule attributeID="email">
             <PermitValueRule xsi:type="ANY" />
         </AttributeRule>
     </AttributeFilterPolicy>

So at userinfo it seems that filtering is on the SP's entityID; while at the user's login it is on the scopes.

Don't know if that's how it's supposed to go.

Jim

-- 
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net