Re: Passing down arbitrary auth attributes down to Realm#authenticate()
Michael, On 5/8/24 03:01, Michael Osipov wrote: On 2024/05/07 21:10:33 Christopher Schultz wrote: Michael, On 5/7/24 14:06, Michael Osipov wrote: Folks, I am working on a custom Authenticator and Realm where I need to pass down a custom value to Realm#authenticate(), more specially a value obtained from javax.security.auth.Subject#getPrivateCredentials(). Currently, there is no such facility in the interface. Any idea how to pass this down w/o touching the interface and w/o thread-local values? The only thing I can think of is a custom realm interface, but that means every realm needs to implement it... This is the entire reason that the securityfilter[1] project exists. It's quite old but gets around this kind of thing with... a custom interface. We use it at $work because we want to be able to get IP addresses to log logins and login failures. Tomcat's Realm-related interfaces have always been too restrictive for me, but I'm not entirely sure how to get around them. I had a conversation with markt years ago at an ApacheCon event where I asked about strategies to help out with this sort of thing, and his relatively quick answer without thinking about it too much was to suggest that (a) anything new and major should probably go into the JASPIC/Jakarta Authentication component and (b) JASPIC/Jakarta Authentication might already be able to do what I wanted. I didn't follow-up at the time, so I can't validate whether he was right about (b) or whether (a) would have been particularly easy/hard. Chris, that SF project seems quite abandoned :-( It's more like "in the attic". It does what it needs to do and has been doing it for years. No need to mess around with it. I took once a brief look at JASPIC. I must say it may be the solution to my problem, but currently I am not capable of rewriting the entire code base for it. I Still prefer CMS over "custom" because it gives me subjective better integration. That's fair. I've never dug far enough into JASPIC / Jakarta Authentication to even know how to implement "standard" Tomcat Authenticator / Realm with a simple RDBMS-based user db. So it's possible it's an afternoon of work to re-build what I need on top of JASPIC (as a Provider) or maybe it's weeks which isn't worth it to me. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Passing down arbitrary auth attributes down to Realm#authenticate()
On 2024/05/07 21:10:33 Christopher Schultz wrote: > Michael, > > On 5/7/24 14:06, Michael Osipov wrote: > > Folks, > > > > I am working on a custom Authenticator and Realm where I need to pass > > down a custom value to Realm#authenticate(), more specially a value > > obtained from javax.security.auth.Subject#getPrivateCredentials(). > > Currently, there is no such facility in the interface. Any idea how to > > pass this down w/o touching the interface and w/o thread-local values? > > The only thing I can think of is a custom realm interface, but that > > means every realm needs to implement it... > > This is the entire reason that the securityfilter[1] project exists. > It's quite old but gets around this kind of thing with... a custom > interface. We use it at $work because we want to be able to get IP > addresses to log logins and login failures. > > Tomcat's Realm-related interfaces have always been too restrictive for > me, but I'm not entirely sure how to get around them. > > I had a conversation with markt years ago at an ApacheCon event where I > asked about strategies to help out with this sort of thing, and his > relatively quick answer without thinking about it too much was to > suggest that (a) anything new and major should probably go into the > JASPIC/Jakarta Authentication component and (b) JASPIC/Jakarta > Authentication might already be able to do what I wanted. > > I didn't follow-up at the time, so I can't validate whether he was right > about (b) or whether (a) would have been particularly easy/hard. Chris, that SF project seems quite abandoned :-( I took once a brief look at JASPIC. I must say it may be the solution to my problem, but currently I am not capable of rewriting the entire code base for it.I Still prefer CMS over "custom" because it gives me subjective better integration. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Passing down arbitrary auth attributes down to Realm#authenticate()
On 2024/05/07 18:20:46 Mark Thomas wrote:
> On 07/05/2024 19:06, Michael Osipov wrote:
> > Folks,
> >
> > I am working on a custom Authenticator and Realm where I need to pass
> > down a custom value to Realm#authenticate(), more specially a value
> > obtained from javax.security.auth.Subject#getPrivateCredentials().
> > Currently, there is no such facility in the interface. Any idea how to
> > pass this down w/o touching the interface and w/o thread-local values?
> > The only thing I can think of is a custom realm interface, but that
> > means every realm needs to implement it...
>
> Cast to your custom Realm in your custom Authenticator and then call any
> method you like? It sounds like the Realm and Authenticator are coupled
> together anyway.
Yes, but not quite. The authenticator does work with any realm Tomcat provides,
but should also provide this custom realm of mine. So I will likely consider:
if (realm instanceof CustomRealm) {
doFoo()
} else{
doBar()
}
Thanks Mark!
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Passing down arbitrary auth attributes down to Realm#authenticate()
Michael, On 5/7/24 14:06, Michael Osipov wrote: Folks, I am working on a custom Authenticator and Realm where I need to pass down a custom value to Realm#authenticate(), more specially a value obtained from javax.security.auth.Subject#getPrivateCredentials(). Currently, there is no such facility in the interface. Any idea how to pass this down w/o touching the interface and w/o thread-local values? The only thing I can think of is a custom realm interface, but that means every realm needs to implement it... This is the entire reason that the securityfilter[1] project exists. It's quite old but gets around this kind of thing with... a custom interface. We use it at $work because we want to be able to get IP addresses to log logins and login failures. Tomcat's Realm-related interfaces have always been too restrictive for me, but I'm not entirely sure how to get around them. I had a conversation with markt years ago at an ApacheCon event where I asked about strategies to help out with this sort of thing, and his relatively quick answer without thinking about it too much was to suggest that (a) anything new and major should probably go into the JASPIC/Jakarta Authentication component and (b) JASPIC/Jakarta Authentication might already be able to do what I wanted. I didn't follow-up at the time, so I can't validate whether he was right about (b) or whether (a) would have been particularly easy/hard. -chris [1] https://securityfilter.sourceforge.net/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Passing down arbitrary auth attributes down to Realm#authenticate()
On 07/05/2024 19:06, Michael Osipov wrote: Folks, I am working on a custom Authenticator and Realm where I need to pass down a custom value to Realm#authenticate(), more specially a value obtained from javax.security.auth.Subject#getPrivateCredentials(). Currently, there is no such facility in the interface. Any idea how to pass this down w/o touching the interface and w/o thread-local values? The only thing I can think of is a custom realm interface, but that means every realm needs to implement it... Cast to your custom Realm in your custom Authenticator and then call any method you like? It sounds like the Realm and Authenticator are coupled together anyway. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
