openid plugin and attributes
Jim Fox
fox at washington.edu
Tue May 3 17:18:28 EDT 2016
v2? isn't v2's end-of-life right about now?
Jim
On Tue, 3 May 2016, Paul Hethmon wrote:
> Date: Tue, 3 May 2016 13:00:27
> From: Paul Hethmon <paul.hethmon at clareitysecurity.com>
> To: Shibboleth Dev <dev at shibboleth.net>
> Reply-To: Shib Dev <dev at shibboleth.net>
> Subject: Re: openid plugin and attributes
>
>
>> On May 3, 2016, at 2:04 PM, Jim Fox <fox at washington.edu> wrote:
>>
>> 1) OIDC requires some extra data about client RPs, e.g. client ID (usually a uuid of some sort). Would these fit into SAML metadata?
>
> I couldn’t find a good way to fit the OIDC “metadata” (very loose term there) into SAML metadata. So there are some additions to the core Shib configuration files (internal.xml, handler.xml) to bootstrap the OIDC components. At that point, the OIDC configuration manager reads some JSON formatted files for core configuration data and for RP information. However, the client ID and client secret/password I modeled as a simple BASIC authentication method. For my IdP’s, I run a BASIC auth filter for ECP purposes and simply used it to protect that endpoint. So whatever method you use to protect it will work.
>
>>
>> 2) OIDC requires direct, non-browser, communication between RP and IP. A lot of Shib IdPs run without activating attribute query and such as it allows for easier clustering. Does your plug-in use shib's state sharing mechanism? If so, can it be activated only for OIDC accesses?
>
> I’m piggy backing on my v2 db storage service. I have extended it to have direct support for storing OIDC sessions. With the direct back channel model of OIDC, I just didn’t see a way to support it without clustering the sessions.
>
> cheers,
>
> Paul
>
> -----
> Paul Hethmon
> Chief Software Architect
> paul.hethmon at clareitysecurity.com
>
>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
More information about the dev
mailing list