Protecting my OIDC dynamic client registration endpoint in Tomcat

[Wessel, Keith]

Sorry, Scott, you said the container is what's at play here in your last reply. I knew that; after all, that's why it's called container-level authentication. I misspoke making it sound like it had anything to do with the IdP.

Taking a step back here, though, the spec [1] states that the registration endpoint can be protected using an access token provisioned out-of-band. This is probably what I should have been doing instead of protecting it with HTTP basic auth and a username/password.

So, this is probably a question for Henri: am I correct that the IdP extension currently doesn't support verification of an access token to protect the client registration endpoint? If so, is this on the roadmap?

Thanks,
Keith

[1] https://openid.net/specs/openid-connect-registration-1_0.html#ClientRegistration

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Tuesday, September 22, 2020 5:01 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Protecting my OIDC dynamic client registration endpoint in Tomcat

On 9/22/20, 5:37 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    Given all that, I'll consider just limiting it to campus IP space. But if I do attempt the JAAS thing, you say the realm
> name typically maches the JAAS application it uses. It aht something standard if it's coming from the IdP?

This is a container thing, it has nothing to do with the IdP.

> Or is it more custom than that? I've seen the various web.xml pieces that need to be wired together and think I get that
> part.

That's all there is (along with whatever else is involved in the container to "trigger" JAAS for the container or the webapp context.

I haven't done any of that for a while, and I don't remember at all whether I ever figured out to do it with Jetty. I thnk that was one case Tomcat was much easier to deal with.

>    I'd love for someone to inform me that it's wrong to protect this flow.

I don't know what OIDC "intends" it be used to do. If it's like SCIM and it's just "security is out of scope", then indeed it really needs to be built differently to support more of the IdP's machinery to really be usable. That includes invoking our AccessControl layer also, obviously.

-- Scott


-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net