OIDC Survey Working Group

[Nick Roy <>]

If I2 staff use cases count, mine are like Dave's, but minus the 
students and plus I want to include Roland's work on federation so my 
lunch doesn't get eaten by Google ;-)

FYI, I just saw an R&S application go through today for a set of APIs 
for use in collaborative research.  That would be the first time I've 
ever seen that - it was for the University of Nebraska Medical Center.  
Would be good to try to get someone from U. Nebraska on this list to 
find out more about _that_ use case.

Brett Bieber from UNL is not on the list, any interest in me asking him 
to join?

Thanks,

Nick

On 10/3/16 6:52 AM, David Langenberg wrote:
> 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