OIDC Survey Working Group

[David Langenberg <>]

On 9/30/16, 12:32 PM, 
"
 on behalf of Patrick Radtke" 
<
 on behalf of 
>
 wrote:

>On Fri, Sep 30, 2016 at 10:12 AM, Eric Goodman 
><>
> wrote:
>> Maybe beyond the scope of this survey, but I’m wondering if the AAF 
>> approach
>> presented is a good model: standardize the communication between the proxy
>> and the application and put support for that layer of communication in the
>> various application libraries, but still leave the protocol handling 
>> outside
>> of the application.
>
>I was expecting the majority of use cases to be driven by mobile apps
>and API access. For mobile - proxying and REMOTE_USER aren't going to
>be available as options. For API access, there may be some
>possibilities - similar to how people off load token validation to an
>API gateway - however fine grain access decisions need knowledge of
>both the data being acted on, the user, and the scopes present in the
>token and that is only exists within the app, and not at the api
>gateway or proxy level.
>
>I wonder, if the proxy approach *is* suitable then why are certain
>groups wanting OIDC? From their application's perspective REMOTE_USER
>is getting set whether it was a SAML authentication or OIDC. Is it
>that the SAML SP on boarding process for their institution is
>cumbersome/hard to understand/not cool/takes weeks/etc? Or is there
>something fundamental about what they want to do that makes the proxy
>not suitable?

Our primary use-case involves API Access for which SAML is not a good fit, 
especially with delegated API access.  Secondarily, the whole "SAML is hard" 
thing is a common refrain.  The students hate SAML because shibboleth/apache 
"isn't cool" and messes up their dev stack which seems to be trending these 
days to Node and Nginx.  Other devs I talk to want the SAML experience to be 
a <dependency> in their pom.xml, some minimal config, and things just work.  

Dave

Attachment: smime.p7s
Description: S/MIME cryptographic signature