Protecting my OIDC dynamic client registration endpoint in Tomcat

[Wessel, Keith]

Scott,

Well, IP limiting it is an option, and it would be a nice interface for something like an external UI to talk to. But there are clients who will want to dynamically register through a programmatic interface. And leaving it open to the world means anyone can freely register a client against my IdP. Nice in theory, but we'd like a bit tighter control over who can register clients. IIRC, the Geant folks recommended protecting this URL back in the early OIDC extension workshops. I'll let Henri correct me if I got that wrong.

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? 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.

I'd love for someone to inform me that it's wrong to protect this flow. If not, I'll propose a feature in Jira for an IdP admin flow. You're very right: that would be much cleaner than what I'm doing here.

Keith


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

I'm not sure the point of the whole model is to limit it, but far be it from me...

It seems to me one obvious thing is just to IP-limit it and use the endpoint as part of a different process for registration I guess.

>    THE OIDC extension doesn't yet seem to have any functionality built in for somehow protecting this endpoint from 
> being open to the world. I started down the JAAS route of telling Tomcat to protect it with Kerberos, but I can't figure
> out how to tell Tomcat what JAAS context to use. That is, what outer block do I put in my jaas.config and how do I
> associate it with the block that I add to my web.xml that includes the /idp/profile/oidc/register URL pattern?

Well, that's container-specific actually, but it's part of wiring together all the bits in web.xml. IIRC, the realm-name element typically matches the JAAS application it uses.

>    Even if I can get this working, I'm then going to have to hard code a list of allowed principals inside my web.xml so that
> client registration isn't open to anyone who can authenticate. Is there some way to do this externally?

Well, you can use a role-name of "**" to mean "any", but doing actual authorization I believe means using Tomcat features to do groups. It doesn't have to be inside we.xml but I don't know how flexible it is.

If this is a really a need, and it's not inherently just "wrong" to protect that endpoint, what is needed is an enhancement to turn that flow into an IdP "admin" flow that can leverage the IdP's authentication layer. Then you can do basically anything the IdP can do, plus use the IdP's access control layer.

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