OIDC Survey Working Group

[Nicholas Roy <>]

FYI

Nick

-------- Forwarded Message --------

Subject:	Re: Quick notes from today's OIDC Survey meeting
Date:	Fri, 7 Oct 2016 15:28:11 +0000
From:	Gloeb, Geoff
To:	Nicholas Roy , Bieber, Brett T

Not necessarily for the research related apps but yes I could see it’s potential in other applications.

 

 

Geoff Gloeb
Senior Analyst
Information Technology Services

University of Nebraska Medical Center
985030 Nebraska Medical Center

Omaha, NE 68198-5030
402-559-5484

 

 

From: Nicholas Roy
Date: Friday, October 7, 2016 at 9:43 AM
To: "Gloeb, Geoff" , "Bieber, Brett T"
Subject: Re: Quick notes from today's OIDC Survey meeting

 

Thanks Geoff - if you think about this use case, would federated support for OpenID Connect be something you'd be interested in?

Best regards,

Nick Roy,
Director of Technology and Strategy, InCommon

On 10/7/16 8:00 AM, Gloeb, Geoff wrote:

It’s not exactly as you’re interpreting.  This SP is a bridge to our research applications.  It’s a simple way to give external PI’s access to all of our apps by way of a post authentication encrypted token.  I could do the same with request maps and redirects but then I’m always in the SP’s config files.  This put’s it back on the application developers to handle the requests.  It also gives them a way to add federated authentication to anything.

 

The Ebola site, NETEC, uses a different SP which is also in R&S.

 

 

Geoff Gloeb
Senior Analyst
Information Technology Services

University of Nebraska Medical Center
985030 Nebraska Medical Center

Omaha, NE 68198-5030
402-559-5484

 

 

From: Brett Bieber
Date: Thursday, October 6, 2016 at 4:42 PM
To: Nicholas Roy , "Gloeb, Geoff"
Subject: Re: Re: Quick notes from today's OIDC Survey meeting

 

We should pull Geoff Gloeb in — he's the resident expert on all things federation at the Med Center.

 

Geoff, would you be willing to talk about the Med Center's use cases as they relate to AuthZ for API endpoints? Was this for the CDC or NIH work you were mentioning to me or something else?

 

 

On Thu, Oct 6, 2016 at 4:32 PM Nicholas Roy <> wrote:

Hi Brett,

Have you considered joining the OIDC survey list?  There seems to be an R&S API protected by SAML at the University of Nebraska Med Center, which suggests that API authZ in a federated context is something the larger community at University of Nebraska might be interested in.

Let me know if you have time to chat about the med center use case and/or have any questions about the OIDC survey group.

Thanks!

Nick

-------- Forwarded Message --------

Subject:	Re: Quick notes from today's OIDC Survey meeting
Date:	Wed, 5 Oct 2016 14:50:10 -0600
From:	Nick Roy
To:

 

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,   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

The information in this e-mail may be privileged and confidential, intended only for the use of the addressee(s) above. Any unauthorized use or disclosure of this information is prohibited. If you have received this e-mail by mistake, please delete it and immediately contact the sender.

The information in this e-mail may be privileged and confidential, intended only for the use of the addressee(s) above. Any unauthorized use or disclosure of this information is prohibited. If you have received this e-mail by mistake, please delete it and immediately contact the sender.