Re: Why does LockOutRealm not support CredentialHandler?
Rémy, On 11/17/22 05:07, Rémy Maucherat wrote: On Wed, Nov 16, 2022 at 6:14 PM Christopher Schultz wrote: Rémy, On 11/16/22 07:53, Rémy Maucherat wrote: On Wed, Nov 16, 2022 at 1:36 PM Christopher Schultz wrote: Thorsten, On 11/16/22 03:20, Thorsten Schöning wrote: Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: That worked right from the start, I had a DIGEST in tomcat-users.xml and was able to login with plain-text password provided to the browser. The use of the word "digest" is overloaded, particularly for this discussion. Please try to use "HTTP DIGEST" when you mean the on-the-wire authentication protocol and "hashed credential" when you mean the stuff you drop into an authentication database. It will make things a lot easier to understand for all parties involved. ... Adding that didn't work, I was only able to login with providing the DIGEST of tomcat-users.xml as password to the browser, which actually made it a plain-text password at the server. The following fit as well to what I recognized: https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm BUT: I gave things an additional try now and especially after the discussion about auth-method BASIC vs. DIGEST and login DOES work now! So both the UserDatabase realm and the LockOutRealm as I suggested above are now working as expected? I most likely not only added LockOutRealm at some point, but switched from BASIC auth to DIGEST as well, because I've read that in the CIS spec I worked with. That combination can't work and at some point I most likely became frustrated and changed DIGEST back to BASIC, while having changed other aspects of the realms already or might have simply forgotten to change passwords vs. digests in tomcat-users.xml or whatever. So, I guess the reason for the warnign about an ignored credential helper in LockOutRealm simply is because it doesn't handle credentials at all? And as LockOutRealm forwards actual login to its children THEIR assigned credential handlers are properly taken into account? Yes, no CombinedRealm ever uses its configured CredentialHandler, which is why the warning is shown. There is a very specific case in which you WANT to configure a CredentialHandler for a CombinedRealm, and that's when your application is using the CredentialHandler directy for certain things. That doesn't seem to be your use-case, so I won't detail that, here. If you re-visit the SO question you posted yesterday, you'll see that I posted an Answer which describes that a little more. So whatever the SO-guy sees, might have a different root cause, as it was the case for me. Thanks for triggering me to try again! Might have been to late already at Monday as well. :-) I'm glad it's working. After reading Rémy's initial response, I was thinking that something needed to be done, but there is no problem IMO. If you need a CredentialHandler in your application, you can still use LockOutRealm (or any other CombinedRealm); you just have to specify a CredentialHandler to use on that outer Realm and all is well. And you have to ignore that warning. Sure, but I plan to try something a little better because why not. I guess we could add a configuration option to CombinedRealm: inheritCredentialHandler="first|last|numeric-position|false/off/no" ? Then you'd only have to declare it once and then you have the flexibility of inheriting it or not. But you'd have to opt-into it instead of getting a surprise. Right now the feature is simply too weird, so I'll simply improve it: - It doesn't work if this is a CombinedRealm, so since they are now used all the time this is rather annoying. - For some reason it only sets the attribute if the Realm is on the Context. For example it will not set anything if the realm is on the Host. So instead, I will make these changes: - CombinedRealm will get its own special credential handler if none is set (it will behave like the nested credential handler, except on nested realm.getCredentialHandler()). So it will just always inherit the CredentialHandler from the first Realm? Make sure it works if there are realms nested N levels deep (e.g. LockOutRealm, SomeCombinedRealm, RealRealm). -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
On Thu, Nov 17, 2022 at 11:22 AM Mark Thomas wrote: > > On 17/11/2022 10:07, Rémy Maucherat wrote: > > On Wed, Nov 16, 2022 at 6:14 PM Christopher Schultz > > > > >> I guess we could add a configuration option to CombinedRealm: > >> > >> inheritCredentialHandler="first|last|numeric-position|false/off/no" > >> > >> ? > >> > >> Then you'd only have to declare it once and then you have the > >> flexibility of inheriting it or not. But you'd have to opt-into it > >> instead of getting a surprise. > > > > Right now the feature is simply too weird, so I'll simply improve it: > > - It doesn't work if this is a CombinedRealm, so since they are now > > used all the time this is rather annoying. > > - For some reason it only sets the attribute if the Realm is on the > > Context. For example it will not set anything if the realm is on the > > Host. > > > > So instead, I will make these changes: > > - CombinedRealm will get its own special credential handler if none is > > set (it will behave like the nested credential handler, except on > > nested realm.getCredentialHandler()). > > - In StandardContext, the attribute will be set based on getRealm() > > instead of getRealmInternal(). > > I don't think we do that as it creates a security concern. An untrusted > application would be able to brute force a Realm it hasn't defined. > > A trusted app can obtain a reference to the Realm via other means. > > I know untrusted apps are rare and becoming rarer but at long as we have > to support the SecurityManager (hopefully not for much longer) then we > have to consider untrusted apps. Ok, I (kind of) understand, and I will remove that part of the change then. Rémy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
On 17/11/2022 10:07, Rémy Maucherat wrote: On Wed, Nov 16, 2022 at 6:14 PM Christopher Schultz I guess we could add a configuration option to CombinedRealm: inheritCredentialHandler="first|last|numeric-position|false/off/no" ? Then you'd only have to declare it once and then you have the flexibility of inheriting it or not. But you'd have to opt-into it instead of getting a surprise. Right now the feature is simply too weird, so I'll simply improve it: - It doesn't work if this is a CombinedRealm, so since they are now used all the time this is rather annoying. - For some reason it only sets the attribute if the Realm is on the Context. For example it will not set anything if the realm is on the Host. So instead, I will make these changes: - CombinedRealm will get its own special credential handler if none is set (it will behave like the nested credential handler, except on nested realm.getCredentialHandler()). - In StandardContext, the attribute will be set based on getRealm() instead of getRealmInternal(). I don't think we do that as it creates a security concern. An untrusted application would be able to brute force a Realm it hasn't defined. A trusted app can obtain a reference to the Realm via other means. I know untrusted apps are rare and becoming rarer but at long as we have to support the SecurityManager (hopefully not for much longer) then we have to consider untrusted apps. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
On Wed, Nov 16, 2022 at 6:14 PM Christopher Schultz wrote: > > Rémy, > > On 11/16/22 07:53, Rémy Maucherat wrote: > > On Wed, Nov 16, 2022 at 1:36 PM Christopher Schultz > > wrote: > >> > >> Thorsten, > >> > >> On 11/16/22 03:20, Thorsten Schöning wrote: > >>> Guten Tag Christopher Schultz, > >>> am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: > >>> > resourceName="UserDatabase"> > className="org.apache.catalina.realm.SecretKeyCredentialHandler" > algorithm="PBKDF2WithHmacSHA512" > iterations="10" > keyLength="256" > saltLength="16" > > >>> > >>> That worked right from the start, I had a DIGEST in tomcat-users.xml > >>> and was able to login with plain-text password provided to the > >>> browser. > >> > >> The use of the word "digest" is overloaded, particularly for this > >> discussion. Please try to use "HTTP DIGEST" when you mean the > >> on-the-wire authentication protocol and "hashed credential" when you > >> mean the stuff you drop into an authentication database. It will make > >> things a lot easier to understand for all parties involved. > >> > > ... > > >>> > >>> Adding that didn't work, I was only able to login with providing the > >>> DIGEST of tomcat-users.xml as password to the browser, which actually > >>> made it a plain-text password at the server. The following fit as well > >>> to what I recognized: > >>> > >>> https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm > >>> > >>> BUT: I gave things an additional try now and especially after the > >>> discussion about auth-method BASIC vs. DIGEST and login DOES work now! > >> > >> So both the UserDatabase realm and the LockOutRealm as I suggested above > >> are now working as expected? > >> > >>> I most likely not only added LockOutRealm at some point, but switched > >>> from BASIC auth to DIGEST as well, because I've read that in the CIS > >>> spec I worked with. That combination can't work and at some point I > >>> most likely became frustrated and changed DIGEST back to BASIC, while > >>> having changed other aspects of the realms already or might have > >>> simply forgotten to change passwords vs. digests in tomcat-users.xml > >>> or whatever. > >>> > >>> So, I guess the reason for the warnign about an ignored credential > >>> helper in LockOutRealm simply is because it doesn't handle credentials > >>> at all? And as LockOutRealm forwards actual login to its children > >>> THEIR assigned credential handlers are properly taken into account? > >> > >> Yes, no CombinedRealm ever uses its configured CredentialHandler, which > >> is why the warning is shown. > >> > >> There is a very specific case in which you WANT to configure a > >> CredentialHandler for a CombinedRealm, and that's when your application > >> is using the CredentialHandler directy for certain things. That doesn't > >> seem to be your use-case, so I won't detail that, here. If you re-visit > >> the SO question you posted yesterday, you'll see that I posted an Answer > >> which describes that a little more. > >> > >>> So whatever the SO-guy sees, might have a different root cause, as it > >>> was the case for me. > >>> > >>> Thanks for triggering me to try again! Might have been to late already > >>> at Monday as well. :-) > >> > >> I'm glad it's working. > >> > >> After reading Rémy's initial response, I was thinking that something > >> needed to be done, but there is no problem IMO. If you need a > >> CredentialHandler in your application, you can still use LockOutRealm > >> (or any other CombinedRealm); you just have to specify a > >> CredentialHandler to use on that outer Realm and all is well. > >> > >> And you have to ignore that warning. > > > > Sure, but I plan to try something a little better because why not. > > I guess we could add a configuration option to CombinedRealm: > > inheritCredentialHandler="first|last|numeric-position|false/off/no" > > ? > > Then you'd only have to declare it once and then you have the > flexibility of inheriting it or not. But you'd have to opt-into it > instead of getting a surprise. Right now the feature is simply too weird, so I'll simply improve it: - It doesn't work if this is a CombinedRealm, so since they are now used all the time this is rather annoying. - For some reason it only sets the attribute if the Realm is on the Context. For example it will not set anything if the realm is on the Host. So instead, I will make these changes: - CombinedRealm will get its own special credential handler if none is set (it will behave like the nested credential handler, except on nested realm.getCredentialHandler()). - In StandardContext, the attribute will be set based on getRealm() instead of getRealmInternal(). Rémy > -chris > >
Re: Why does LockOutRealm not support CredentialHandler?
Rémy, On 11/16/22 07:53, Rémy Maucherat wrote: On Wed, Nov 16, 2022 at 1:36 PM Christopher Schultz wrote: Thorsten, On 11/16/22 03:20, Thorsten Schöning wrote: Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: That worked right from the start, I had a DIGEST in tomcat-users.xml and was able to login with plain-text password provided to the browser. The use of the word "digest" is overloaded, particularly for this discussion. Please try to use "HTTP DIGEST" when you mean the on-the-wire authentication protocol and "hashed credential" when you mean the stuff you drop into an authentication database. It will make things a lot easier to understand for all parties involved. ... Adding that didn't work, I was only able to login with providing the DIGEST of tomcat-users.xml as password to the browser, which actually made it a plain-text password at the server. The following fit as well to what I recognized: https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm BUT: I gave things an additional try now and especially after the discussion about auth-method BASIC vs. DIGEST and login DOES work now! So both the UserDatabase realm and the LockOutRealm as I suggested above are now working as expected? I most likely not only added LockOutRealm at some point, but switched from BASIC auth to DIGEST as well, because I've read that in the CIS spec I worked with. That combination can't work and at some point I most likely became frustrated and changed DIGEST back to BASIC, while having changed other aspects of the realms already or might have simply forgotten to change passwords vs. digests in tomcat-users.xml or whatever. So, I guess the reason for the warnign about an ignored credential helper in LockOutRealm simply is because it doesn't handle credentials at all? And as LockOutRealm forwards actual login to its children THEIR assigned credential handlers are properly taken into account? Yes, no CombinedRealm ever uses its configured CredentialHandler, which is why the warning is shown. There is a very specific case in which you WANT to configure a CredentialHandler for a CombinedRealm, and that's when your application is using the CredentialHandler directy for certain things. That doesn't seem to be your use-case, so I won't detail that, here. If you re-visit the SO question you posted yesterday, you'll see that I posted an Answer which describes that a little more. So whatever the SO-guy sees, might have a different root cause, as it was the case for me. Thanks for triggering me to try again! Might have been to late already at Monday as well. :-) I'm glad it's working. After reading Rémy's initial response, I was thinking that something needed to be done, but there is no problem IMO. If you need a CredentialHandler in your application, you can still use LockOutRealm (or any other CombinedRealm); you just have to specify a CredentialHandler to use on that outer Realm and all is well. And you have to ignore that warning. Sure, but I plan to try something a little better because why not. I guess we could add a configuration option to CombinedRealm: inheritCredentialHandler="first|last|numeric-position|false/off/no" ? Then you'd only have to declare it once and then you have the flexibility of inheriting it or not. But you'd have to opt-into it instead of getting a surprise. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 13:35 schrieben Sie: > I really don't know why you are seeing that warning. You aren't > explicitly-setting a CredentialHandler on your LockOutRealm and > that's the only time this warning should be shown.[...] Yes I did during tests when the credential handler didn't work as expected for the user database. I simply moved it up for test purposes, got the warning and thought there was some fundamental underluying problem. Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
On Wed, Nov 16, 2022 at 1:36 PM Christopher Schultz wrote: > > Thorsten, > > On 11/16/22 03:20, Thorsten Schöning wrote: > > Guten Tag Christopher Schultz, > > am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: > > > >> >> resourceName="UserDatabase"> > >> >> className="org.apache.catalina.realm.SecretKeyCredentialHandler" > >> algorithm="PBKDF2WithHmacSHA512" > >> iterations="10" > >> keyLength="256" > >> saltLength="16" > >> > > > > That worked right from the start, I had a DIGEST in tomcat-users.xml > > and was able to login with plain-text password provided to the > > browser. > > The use of the word "digest" is overloaded, particularly for this > discussion. Please try to use "HTTP DIGEST" when you mean the > on-the-wire authentication protocol and "hashed credential" when you > mean the stuff you drop into an authentication database. It will make > things a lot easier to understand for all parties involved. > > >> > >> ... > >> > > > > Adding that didn't work, I was only able to login with providing the > > DIGEST of tomcat-users.xml as password to the browser, which actually > > made it a plain-text password at the server. The following fit as well > > to what I recognized: > > > > https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm > > > > BUT: I gave things an additional try now and especially after the > > discussion about auth-method BASIC vs. DIGEST and login DOES work now! > > So both the UserDatabase realm and the LockOutRealm as I suggested above > are now working as expected? > > > I most likely not only added LockOutRealm at some point, but switched > > from BASIC auth to DIGEST as well, because I've read that in the CIS > > spec I worked with. That combination can't work and at some point I > > most likely became frustrated and changed DIGEST back to BASIC, while > > having changed other aspects of the realms already or might have > > simply forgotten to change passwords vs. digests in tomcat-users.xml > > or whatever. > > > > So, I guess the reason for the warnign about an ignored credential > > helper in LockOutRealm simply is because it doesn't handle credentials > > at all? And as LockOutRealm forwards actual login to its children > > THEIR assigned credential handlers are properly taken into account? > > Yes, no CombinedRealm ever uses its configured CredentialHandler, which > is why the warning is shown. > > There is a very specific case in which you WANT to configure a > CredentialHandler for a CombinedRealm, and that's when your application > is using the CredentialHandler directy for certain things. That doesn't > seem to be your use-case, so I won't detail that, here. If you re-visit > the SO question you posted yesterday, you'll see that I posted an Answer > which describes that a little more. > > > So whatever the SO-guy sees, might have a different root cause, as it > > was the case for me. > > > > Thanks for triggering me to try again! Might have been to late already > > at Monday as well. :-) > > I'm glad it's working. > > After reading Rémy's initial response, I was thinking that something > needed to be done, but there is no problem IMO. If you need a > CredentialHandler in your application, you can still use LockOutRealm > (or any other CombinedRealm); you just have to specify a > CredentialHandler to use on that outer Realm and all is well. > > And you have to ignore that warning. Sure, but I plan to try something a little better because why not. Rémy > I really don't know why you are seeing that warning. You aren't > explicitly-setting a CredentialHandler on your LockOutRealm and that's > the only time this warning should be shown. When > CombinedRealm.startInternal runs, it creates a trivial CredentialHandler > (I'm not sure why it does that, actually) but only if the reference is > null and then it sets the class member directly instead of calling > setCredentialHandler. > > So I'm still a little confused as to why you are seeing what you are seeing. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Thorsten, On 11/16/22 03:20, Thorsten Schöning wrote: Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: That worked right from the start, I had a DIGEST in tomcat-users.xml and was able to login with plain-text password provided to the browser. The use of the word "digest" is overloaded, particularly for this discussion. Please try to use "HTTP DIGEST" when you mean the on-the-wire authentication protocol and "hashed credential" when you mean the stuff you drop into an authentication database. It will make things a lot easier to understand for all parties involved. ... Adding that didn't work, I was only able to login with providing the DIGEST of tomcat-users.xml as password to the browser, which actually made it a plain-text password at the server. The following fit as well to what I recognized: https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm BUT: I gave things an additional try now and especially after the discussion about auth-method BASIC vs. DIGEST and login DOES work now! So both the UserDatabase realm and the LockOutRealm as I suggested above are now working as expected? I most likely not only added LockOutRealm at some point, but switched from BASIC auth to DIGEST as well, because I've read that in the CIS spec I worked with. That combination can't work and at some point I most likely became frustrated and changed DIGEST back to BASIC, while having changed other aspects of the realms already or might have simply forgotten to change passwords vs. digests in tomcat-users.xml or whatever. So, I guess the reason for the warnign about an ignored credential helper in LockOutRealm simply is because it doesn't handle credentials at all? And as LockOutRealm forwards actual login to its children THEIR assigned credential handlers are properly taken into account? Yes, no CombinedRealm ever uses its configured CredentialHandler, which is why the warning is shown. There is a very specific case in which you WANT to configure a CredentialHandler for a CombinedRealm, and that's when your application is using the CredentialHandler directy for certain things. That doesn't seem to be your use-case, so I won't detail that, here. If you re-visit the SO question you posted yesterday, you'll see that I posted an Answer which describes that a little more. So whatever the SO-guy sees, might have a different root cause, as it was the case for me. Thanks for triggering me to try again! Might have been to late already at Monday as well. :-) I'm glad it's working. After reading Rémy's initial response, I was thinking that something needed to be done, but there is no problem IMO. If you need a CredentialHandler in your application, you can still use LockOutRealm (or any other CombinedRealm); you just have to specify a CredentialHandler to use on that outer Realm and all is well. And you have to ignore that warning. I really don't know why you are seeing that warning. You aren't explicitly-setting a CredentialHandler on your LockOutRealm and that's the only time this warning should be shown. When CombinedRealm.startInternal runs, it creates a trivial CredentialHandler (I'm not sure why it does that, actually) but only if the reference is null and then it sets the class member directly instead of calling setCredentialHandler. So I'm still a little confused as to why you are seeing what you are seeing. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Thorsten, On 11/16/22 02:28, Thorsten Schöning wrote: Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:00 schrieben Sie: Thorsten, what makes you say "it doesn't work" and "LockoutRealm ignores any credential handler"? When you say "it doesn't work"... what DOES it do? IGNORES because it logs a corresponding warning on explicitly configured credential handlers for the LockOutRealm itself and uses a hard-coded default handler, which only allows plain-text passwords in tomcat-users.xml. Does it ignore it? Reading the code suggests that it does not ignore it. Or to be more specific, whatever is input intoc tomcat-users.xml is simply used as plain-text password, so adding a digest based on PBKDF2WithHmacSHA512 won't let you login with the real plain-text provided to the browser by the user. But it allow login when providing the digest as plain-text password. So if you copy/paste the junk that's shown in tomcat-users.xml as the user's "password" (really the PBKDF2 algorithm's output) when challenged by the browser, it lets you in? The code for LockOutRealm and CombinedRealm doesn't look like it works that way. Are you sure you have your Tomcat configured the way you think you do? If credential handlers are configured for child realms, those are simply ignored as well, even without any warning this time. Which makes it additionally difficult to debug this whole setup. I think we might need to see a super-simple setup of this, because your description of experience does not match the way that the code is written, nor the way in which it's intended to work. Can you prepare a configuration for the "examples" web application which demonstrates what you are saying, here, and post it somewhere we can find it? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: > resourceName="UserDatabase"> > className="org.apache.catalina.realm.SecretKeyCredentialHandler" > algorithm="PBKDF2WithHmacSHA512" > iterations="10" > keyLength="256" > saltLength="16" > That worked right from the start, I had a DIGEST in tomcat-users.xml and was able to login with plain-text password provided to the browser. > > ... > Adding that didn't work, I was only able to login with providing the DIGEST of tomcat-users.xml as password to the browser, which actually made it a plain-text password at the server. The following fit as well to what I recognized: https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm BUT: I gave things an additional try now and especially after the discussion about auth-method BASIC vs. DIGEST and login DOES work now! I most likely not only added LockOutRealm at some point, but switched from BASIC auth to DIGEST as well, because I've read that in the CIS spec I worked with. That combination can't work and at some point I most likely became frustrated and changed DIGEST back to BASIC, while having changed other aspects of the realms already or might have simply forgotten to change passwords vs. digests in tomcat-users.xml or whatever. So, I guess the reason for the warnign about an ignored credential helper in LockOutRealm simply is because it doesn't handle credentials at all? And as LockOutRealm forwards actual login to its children THEIR assigned credential handlers are properly taken into account? So whatever the SO-guy sees, might have a different root cause, as it was the case for me. Thanks for triggering me to try again! Might have been to late already at Monday as well. :-) Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:00 schrieben Sie: > Thorsten, what makes you say "it doesn't work" and "LockoutRealm > ignores any credential handler"? When you say "it doesn't work"... > what DOES it do? IGNORES because it logs a corresponding warning on explicitly configured credential handlers for the LockOutRealm itself and uses a hard-coded default handler, which only allows plain-text passwords in tomcat-users.xml. Or to be more specific, whatever is input intoc tomcat-users.xml is simply used as plain-text password, so adding a digest based on PBKDF2WithHmacSHA512 won't let you login with the real plain-text provided to the browser by the user. But it allow login when providing the digest as plain-text password. If credential handlers are configured for child realms, those are simply ignored as well, even without any warning this time. Which makes it additionally difficult to debug this whole setup. > In Tomcat 10 BTW, the "digest" attribute has been removed in favor > of a properly-configured . Note that you can't > use "digest" and also get acceptable security out of the Realm, anyway. Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Thorsten, On 11/15/22 05:09, Thorsten Schöning wrote: I have some webapp hosted by Tomcat and need to restrict user access to some part of that. One additional requirement is that this app needs to be CIS benchmark compliant and that requires to use LockOutRealm and restricts to store plain-text passwords. Therefore, the ultimate solution in my case would be the following: But that doesn't work, because LockOutRealm ignores any credential handler. Does it? Additionally, with my used Tomcat 10, I'm unable to set any "digest" attribute on the realm itself anymore as well. Forget about "digest". It's dead and for good reason. The only way to fulfill both requirements is to implement a custom realm. That should not be true. Nov 14, 2022 9:03:48 PM org.apache.catalina.realm.CombinedRealm setCredentialHandler WARNUNG: A CredentialHandler was set on an instance of the CombinedRealm (or a sub-class of CombinedRealm). CombinedRealm doesn't use a configured CredentialHandler. Is this a configuration error? https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/LocalStrings.properties#L23 https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/CombinedRealm.java#L466 https://tomcat.apache.org/tomcat-9.0-doc/changelog.html https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm So, what's the reason of not supporting credential handlers for LockOutRealm? They are supported. Doesn't make too much sense to me, especially as most docs I came across use LockOutRealm in combination with some other realm and there's no docs that a fundamental concept like credential helpers won't work at all in this setup. Additionally, when researching about that task, some people even claim that the above XML config works, but it simply can't. ? I don't see any code in LockOutRealm to ask other realms about their credential handlers. Nor do you need any such code. I've had a look at the bugtracker already and couldn't find this topic discussed or a reason for the implementation. OTOH, someone did add some code to explicitly log a warning message instead of fixing the underlying problem. I'm not sure there is an "underlying problem" that needs fixing. Is the problem really to decide which of the child realms to choose for its credential handler to use? No. In the easiest case simply use the first credential handler found with a depth-first search, that should work for the majority of use-cases. No. Other aspects of the config like default assumed nesting level of realms and stuff seem hard-coded as well. Really? Like what? Would be glad to read some thoughts, as I need to decide how to deal with this limitation right now. Thanks! What happens if you configure your realm like this: resourceName="UserDatabase"> className="org.apache.catalina.realm.SecretKeyCredentialHandler" algorithm="PBKDF2WithHmacSHA512" iterations="10" keyLength="256" saltLength="16" Are you able to login to your application? If not, get that working first. Once that's working, try wrapping the above in: ... Rebuild, restart, and try logging-in again. Are you able to login? If not, please let us know. If you are able to login, then try logging-in a few times with the wrong password. Are you locked out? (Do you know how to verify that?) All of that should work. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Rémy and Thorsten, On 11/15/22 06:59, Rémy Maucherat wrote: On Tue, Nov 15, 2022 at 11:11 AM Thorsten Schöning wrote: Hi everyone, I have some webapp hosted by Tomcat and need to restrict user access to some part of that. One additional requirement is that this app needs to be CIS benchmark compliant and that requires to use LockOutRealm and restricts to store plain-text passwords. Therefore, the ultimate solution in my case would be the following: But that doesn't work, because LockOutRealm ignores any credential handler. Additionally, with my used Tomcat 10, I'm unable to set any "digest" attribute on the realm itself anymore as well. The only way to fulfill both requirements is to implement a custom realm. Nov 14, 2022 9:03:48 PM org.apache.catalina.realm.CombinedRealm setCredentialHandler WARNUNG: A CredentialHandler was set on an instance of the CombinedRealm (or a sub-class of CombinedRealm). CombinedRealm doesn't use a configured CredentialHandler. Is this a configuration error? https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/LocalStrings.properties#L23 https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/CombinedRealm.java#L466 https://tomcat.apache.org/tomcat-9.0-doc/changelog.html https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm So, what's the reason of not supporting credential handlers for LockOutRealm? Doesn't make too much sense to me, especially as most docs I came across use LockOutRealm in combination with some other realm and there's no docs that a fundamental concept like credential helpers won't work at all in this setup. Additionally, when researching about that task, some people even claim that the above XML config works, but it simply can't. I don't see any code in LockOutRealm to ask other realms about their credential handlers. I've had a look at the bugtracker already and couldn't find this topic discussed or a reason for the implementation. OTOH, someone did add some code to explicitly log a warning message instead of fixing the underlying problem. Is the problem really to decide which of the child realms to choose for its credential handler to use? In the easiest case simply use the first credential handler found with a depth-first search, that should work for the majority of use-cases. Other aspects of the config like default assumed nesting level of realms and stuff seem hard-coded as well. Would be glad to read some thoughts, as I need to decide how to deal with this limitation right now. Thanks! Ok, this is a bit confusing. Everything is configured properly if you nest the CredentialHandler on the right realm (the UserDatabaseRealm). However, the CredentialHandler exposed by getAttribute(Globals.CREDENTIAL_HANDLER) is always the CredentialHandler from the realm attached to the context, here it is LockOutRealm, which isn't very useful. Hmm. You're absolutely right, and it's probably my mistake by doing that. I'll review the code. When you have nested Realms (e.g. CombinedRealm) things can get ... weird if you have multiple credential handlers on each one. It may not always be obvious which one to choose or how to combine them. So interrogating the outer realm for a credential-handler may not really be possible without just explicitly-setting a credential handler that knows what to do on the outermost realm. Maybe NestedCredentialHandler could be used to construct a CredentialHandler that could be useful to the application, but this needs more thought. The CredentialHandler set in the application scope is indeed intended to be used by the application, for example to allow for in-app password changes. The idea is that the application should be able to use the same password-mangling rules used by Tomcat without necessarily having to know what those rules are. Thorsten, what makes you say "it doesn't work" and "LockoutRealm ignores any credential handler"? When you say "it doesn't work"... what DOES it do? In Tomcat 10 BTW, the "digest" attribute has been removed in favor of a properly-configured . Note that you can't use "digest" and also get acceptable security out of the Realm, anyway. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Guten Tag Rémy Maucherat, am Dienstag, 15. November 2022 um 12:59 schrieben Sie: > Maybe NestedCredentialHandler could be used to construct a > CredentialHandler that could be useful to the application, but this > needs more thought. That wouldn't change anything, as that handler would be ignored and/or warned about again. The problem is the strategy from which realm to get the handler and a depth-first approach seems to make most sense. I've created a bit now, this should at least be documented as widely as possible. In the best case even enhanced of course. https://bz.apache.org/bugzilla/show_bug.cgi?id=66349 Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
On Tue, Nov 15, 2022 at 11:11 AM Thorsten Schöning wrote: > > Hi everyone, > > I have some webapp hosted by Tomcat and need to restrict user access > to some part of that. One additional requirement is that this app > needs to be CIS benchmark compliant and that requires to use > LockOutRealm and restricts to store plain-text passwords. Therefore, > the ultimate solution in my case would be the following: > > > > >> resourceName="UserDatabase"> > > > className="org.apache.catalina.realm.SecretKeyCredentialHandler" > > algorithm="PBKDF2WithHmacSHA512" > > iterations="10" > > keyLength="256" > > saltLength="16" > > /> > > > > > > But that doesn't work, because LockOutRealm ignores any credential > handler. Additionally, with my used Tomcat 10, I'm unable to set any > "digest" attribute on the realm itself anymore as well. The only way > to fulfill both requirements is to implement a custom realm. > > > Nov 14, 2022 9:03:48 PM org.apache.catalina.realm.CombinedRealm > > setCredentialHandler > > WARNUNG: A CredentialHandler was set on an instance of the > > CombinedRealm (or a sub-class of CombinedRealm). CombinedRealm > > doesn't use a configured CredentialHandler. Is this a configuration > > error? > > https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/LocalStrings.properties#L23 > https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/CombinedRealm.java#L466 > https://tomcat.apache.org/tomcat-9.0-doc/changelog.html > https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm > > So, what's the reason of not supporting credential handlers for > LockOutRealm? > > Doesn't make too much sense to me, especially as most docs I came > across use LockOutRealm in combination with some other realm and > there's no docs that a fundamental concept like credential helpers > won't work at all in this setup. Additionally, when researching about > that task, some people even claim that the above XML config works, but > it simply can't. I don't see any code in LockOutRealm to ask other > realms about their credential handlers. > > I've had a look at the bugtracker already and couldn't find this topic > discussed or a reason for the implementation. OTOH, someone did add > some code to explicitly log a warning message instead of fixing the > underlying problem. > > Is the problem really to decide which of the child realms to choose > for its credential handler to use? In the easiest case simply use the > first credential handler found with a depth-first search, that should > work for the majority of use-cases. Other aspects of the config like > default assumed nesting level of realms and stuff seem hard-coded as > well. > > Would be glad to read some thoughts, as I need to decide how to deal > with this limitation right now. Thanks! Ok, this is a bit confusing. Everything is configured properly if you nest the CredentialHandler on the right realm (the UserDatabaseRealm). However, the CredentialHandler exposed by getAttribute(Globals.CREDENTIAL_HANDLER) is always the CredentialHandler from the realm attached to the context, here it is LockOutRealm, which isn't very useful. Maybe NestedCredentialHandler could be used to construct a CredentialHandler that could be useful to the application, but this needs more thought. Rémy > > Mit freundlichen Grüßen > > Thorsten Schöning > > -- > AM-SoFT IT-Service - Bitstore Hameln GmbH > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK > > E-Mail: thorsten.schoen...@am-soft.de > Web:http://www.AM-SoFT.de/ > > Tel: +49 5151- 9468- 0 > Tel: +49 5151- 9468-55 > Mobil: +49 178-8 9468-04 > > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska > > > Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > > Telefon: +49 5151 9468-55 > Fax: > E-Mail: tschoen...@am-soft.de > > AM-Soft IT-Service - Bitstore Hameln GmbH > Brandenburger Straße 7c > 31789 Hameln > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen > und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf > diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie > nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, > informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. > Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen > jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das > Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte > Information untersagt. > > This e-mail may contain confidenti
Why does LockOutRealm not support CredentialHandler?
Hi everyone, I have some webapp hosted by Tomcat and need to restrict user access to some part of that. One additional requirement is that this app needs to be CIS benchmark compliant and that requires to use LockOutRealm and restricts to store plain-text passwords. Therefore, the ultimate solution in my case would be the following: > >resourceName="UserDatabase"> > className="org.apache.catalina.realm.SecretKeyCredentialHandler" > algorithm="PBKDF2WithHmacSHA512" > iterations="10" > keyLength="256" > saltLength="16" > /> > > But that doesn't work, because LockOutRealm ignores any credential handler. Additionally, with my used Tomcat 10, I'm unable to set any "digest" attribute on the realm itself anymore as well. The only way to fulfill both requirements is to implement a custom realm. > Nov 14, 2022 9:03:48 PM org.apache.catalina.realm.CombinedRealm > setCredentialHandler > WARNUNG: A CredentialHandler was set on an instance of the > CombinedRealm (or a sub-class of CombinedRealm). CombinedRealm > doesn't use a configured CredentialHandler. Is this a configuration > error? https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/LocalStrings.properties#L23 https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/CombinedRealm.java#L466 https://tomcat.apache.org/tomcat-9.0-doc/changelog.html https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm So, what's the reason of not supporting credential handlers for LockOutRealm? Doesn't make too much sense to me, especially as most docs I came across use LockOutRealm in combination with some other realm and there's no docs that a fundamental concept like credential helpers won't work at all in this setup. Additionally, when researching about that task, some people even claim that the above XML config works, but it simply can't. I don't see any code in LockOutRealm to ask other realms about their credential handlers. I've had a look at the bugtracker already and couldn't find this topic discussed or a reason for the implementation. OTOH, someone did add some code to explicitly log a warning message instead of fixing the underlying problem. Is the problem really to decide which of the child realms to choose for its credential handler to use? In the easiest case simply use the first credential handler found with a depth-first search, that should work for the majority of use-cases. Other aspects of the config like default assumed nesting level of realms and stuff seem hard-coded as well. Would be glad to read some thoughts, as I need to decide how to deal with this limitation right now. Thanks! Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
