You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Quintin Beukes (JIRA)" <ji...@apache.org> on 2009/09/04 21:36:57 UTC
[jira] Created: (GERONIMO-4848) Application Client Login Retries
Application Client Login Retries
--------------------------------
Key: GERONIMO-4848
URL: https://issues.apache.org/jira/browse/GERONIMO-4848
Project: Geronimo
Issue Type: New Feature
Security Level: public (Regular issues)
Components: application client, security
Affects Versions: 2.1.4
Reporter: Quintin Beukes
Priority: Minor
When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
- It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
...
<lc:login-module control-flag="REQUIRED">
<lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
<lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
<lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
<lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
<lc:option name="FailedLoginTries">3</lc:option>
</lc:login-module>
...
- If you omit this option, it will default to the current behaviour of "1" try.
- If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
- If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
Note: The "cancel" check works for all logins, including the first try.
- Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
- If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
Posted by "Quintin Beukes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Quintin Beukes updated GERONIMO-4848:
-------------------------------------
Attachment: OpenejbRemoteLoginModule.java
login-retries.patch
Patch for the new login module, as well as the complete class for those who wish to view it without having to first apply the patch.
> Application Client Login Retries
> --------------------------------
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
> Affects Versions: 2.1.4
> Reporter: Quintin Beukes
> Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
> ...
> <lc:login-module control-flag="REQUIRED">
> <lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
> <lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
> <lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
> <lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
> <lc:option name="FailedLoginTries">3</lc:option>
> </lc:login-module>
> ...
> - If you omit this option, it will default to the current behaviour of "1" try.
> - If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
Posted by "Quintin Beukes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Quintin Beukes updated GERONIMO-4848:
-------------------------------------
Attachment: OpenejbRemoteLoginModule.java-2.2
login-retries-2.2.patch
Geronimo 2.2 doesn't use Commons Logging anymore, so this is the same modification as above, except with the slf4j logger change applied.
>From 2.1.4 to 2.2 this file hasn't changed, so it should be fine to apply it.
Explanation:
OpenejbRemoteLoginModule.java-2.2 - a full .java for Geronimo 2.2
login-retries-2.2.patch - A patch to transform Geronimo 2.2's login module adding the login-retries.
> Application Client Login Retries
> --------------------------------
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
> Affects Versions: 2.1.4
> Reporter: Quintin Beukes
> Priority: Minor
> Attachments: login-retries-2.2.patch, login-retries.patch, OpenejbRemoteLoginModule.java, OpenejbRemoteLoginModule.java-2.2
>
>
> When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
> ...
> <lc:login-module control-flag="REQUIRED">
> <lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
> <lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
> <lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
> <lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
> <lc:option name="FailedLoginTries">3</lc:option>
> </lc:login-module>
> ...
> - If you omit this option, it will default to the current behaviour of "1" try.
> - If you supply an invalid value for an option (any value that would raise a NumberFormatException when calling "Integer.parseInt()"), it will default to the current behaviour of "1" try.
> - If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
Posted by "Quintin Beukes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Quintin Beukes updated GERONIMO-4848:
-------------------------------------
Attachment: login-retries.patch
OpenejbRemoteLoginModule.java
Patch as described in the issue's description as well as the full class to read the code without having to patch an older version.
> Application Client Login Retries
> --------------------------------
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
> Affects Versions: 2.1.4
> Reporter: Quintin Beukes
> Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
> ...
> <lc:login-module control-flag="REQUIRED">
> <lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
> <lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
> <lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
> <lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
> <lc:option name="FailedLoginTries">3</lc:option>
> </lc:login-module>
> ...
> - If you omit this option, it will default to the current behaviour of "1" try.
> - If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
Posted by "Quintin Beukes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Quintin Beukes updated GERONIMO-4848:
-------------------------------------
Comment: was deleted
(was: Patch for the new login module, as well as the complete class for those who wish to view it without having to first apply the patch.)
> Application Client Login Retries
> --------------------------------
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
> Affects Versions: 2.1.4
> Reporter: Quintin Beukes
> Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
> ...
> <lc:login-module control-flag="REQUIRED">
> <lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
> <lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
> <lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
> <lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
> <lc:option name="FailedLoginTries">3</lc:option>
> </lc:login-module>
> ...
> - If you omit this option, it will default to the current behaviour of "1" try.
> - If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
Posted by "Quintin Beukes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Quintin Beukes updated GERONIMO-4848:
-------------------------------------
Attachment: (was: OpenejbRemoteLoginModule.java)
> Application Client Login Retries
> --------------------------------
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
> Affects Versions: 2.1.4
> Reporter: Quintin Beukes
> Priority: Minor
>
> When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
> ...
> <lc:login-module control-flag="REQUIRED">
> <lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
> <lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
> <lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
> <lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
> <lc:option name="FailedLoginTries">3</lc:option>
> </lc:login-module>
> ...
> - If you omit this option, it will default to the current behaviour of "1" try.
> - If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
Posted by "Quintin Beukes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Quintin Beukes updated GERONIMO-4848:
-------------------------------------
Description:
When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
- It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
...
<lc:login-module control-flag="REQUIRED">
<lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
<lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
<lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
<lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
<lc:option name="FailedLoginTries">3</lc:option>
</lc:login-module>
...
- If you omit this option, it will default to the current behaviour of "1" try.
- If you supply an invalid value for an option (any value that would raise a NumberFormatException when calling "Integer.parseInt()"), it will default to the current behaviour of "1" try.
- If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
- If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
Note: The "cancel" check works for all logins, including the first try.
- Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
- If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
Any suggestions/requests, just let me know and I'll implement them.
was:
When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
- It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
...
<lc:login-module control-flag="REQUIRED">
<lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
<lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
<lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
<lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
<lc:option name="FailedLoginTries">3</lc:option>
</lc:login-module>
...
- If you omit this option, it will default to the current behaviour of "1" try.
- If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
- If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
Note: The "cancel" check works for all logins, including the first try.
- Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
- If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
Any suggestions/requests, just let me know and I'll implement them.
> Application Client Login Retries
> --------------------------------
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
> Affects Versions: 2.1.4
> Reporter: Quintin Beukes
> Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
> ...
> <lc:login-module control-flag="REQUIRED">
> <lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
> <lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
> <lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
> <lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
> <lc:option name="FailedLoginTries">3</lc:option>
> </lc:login-module>
> ...
> - If you omit this option, it will default to the current behaviour of "1" try.
> - If you supply an invalid value for an option (any value that would raise a NumberFormatException when calling "Integer.parseInt()"), it will default to the current behaviour of "1" try.
> - If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-4848) Application Client
Login Retries
Posted by "Quintin Beukes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751590#action_12751590 ]
Quintin Beukes edited comment on GERONIMO-4848 at 9/4/09 12:47 PM:
-------------------------------------------------------------------
I named the option "FailedLoginTries". It was actually renamed from "FailedLoginRetries", but after I changed it's purpose, I changed to "Tries", but didn't realize that the name is deceiving.
I changed the option to "LoginAttempts", so the attached patch and class will use "LoginAttempts" instead.
was (Author: quintin@last.za.net):
I named the option "FailedLoginTries". It was actually renamed from "FailedLoginRetries", but after I changed it's purpose, I changed to "Tries", but didn't realize that the name is deceiving.
A better name might be "LoginAttempts".
> Application Client Login Retries
> --------------------------------
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
> Affects Versions: 2.1.4
> Reporter: Quintin Beukes
> Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
> ...
> <lc:login-module control-flag="REQUIRED">
> <lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
> <lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
> <lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
> <lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
> <lc:option name="FailedLoginTries">3</lc:option>
> </lc:login-module>
> ...
> - If you omit this option, it will default to the current behaviour of "1" try.
> - If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4848) Application Client Login Retries
Posted by "Quintin Beukes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751590#action_12751590 ]
Quintin Beukes commented on GERONIMO-4848:
------------------------------------------
I named the option "FailedLoginTries". It was actually renamed from "FailedLoginRetries", but after I changed it's purpose, I changed to "Tries", but didn't realize that the name is deceiving.
A better name might be "LoginAttempts".
> Application Client Login Retries
> --------------------------------
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
> Affects Versions: 2.1.4
> Reporter: Quintin Beukes
> Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
> ...
> <lc:login-module control-flag="REQUIRED">
> <lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
> <lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
> <lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
> <lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
> <lc:option name="FailedLoginTries">3</lc:option>
> </lc:login-module>
> ...
> - If you omit this option, it will default to the current behaviour of "1" try.
> - If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
Posted by "Quintin Beukes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Quintin Beukes updated GERONIMO-4848:
-------------------------------------
Attachment: (was: login-retries.patch)
> Application Client Login Retries
> --------------------------------
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
> Affects Versions: 2.1.4
> Reporter: Quintin Beukes
> Priority: Minor
>
> When an application client is configured to authenticate with a JAAS realm and a CallbackHandler, the login is performed before the application's main method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional extra "option", which can be specified in the gbean configuration, like so:
> ...
> <lc:login-module control-flag="REQUIRED">
> <lc:login-domain-name>remote-openejb-realm</lc:login-domain-name>
> <lc:login-module-class>net.kunye.platform.security.auth.ApplicationClientLoginModule</lc:login-module-class>
> <lc:option name="RemoteSecurityRealm">KMSRealm</lc:option>
> <lc:option name="ServerURI">ejbd://localhost:4201</lc:option>
> <lc:option name="FailedLoginTries">3</lc:option>
> </lc:login-module>
> ...
> - If you omit this option, it will default to the current behaviour of "1" try.
> - If you specify an integer great or equal to 0, it will perform the given amount of tries. If no successful authentication occurred during these tries it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a successful authentication or the user cancelled. The cancel is detected by setting either the NameCallback or PasswordCallback's value to null. This is quite unintuitive and might make it more difficult to find bugs in your code where the values are unintentionally null, so an alternative way might be better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a single TextOutputCallback which contains an INFORMATION type message "Login cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single TextOutputCallback which contains an ERROR type message "Login failed for user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the application client is to have more direct access to the CallbackHandler, so as to send the "Login Failed" and "Login canceled" messages. Also the fact that certain types of login modules might be used which don't support the "concept" of a retry, like host based authentication modules. So doing retries in the application client layer didn't seem logical. This way you can also extend the class or build your own and ship it with your application, and so be able to customize the retry behaviour, instead of relying on a fixed retry strategy in the application client layer (which could only be changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.