[JBoss-user] [Security & JAAS/JBoss] - Re: limitations of ClientLoginModule and security model
Using static methods of the the JACC javax.security.jacc.PolicyContext object,
you can use
Code:
HttpServletRequest request =
(HttpServletRequest)PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
So you can get any parameters from the login form that you want.
Using javax.security.jacc.PolicyContext.getHandlerKeys(), in my LoginModule, I
find
PolicyContext has "javax.ejb.arguments"
PolicyContext has "javax.servlet.http.HttpServletRequest". It is a
org.apache.catalina.connector.RequestFacade
PolicyContext has "javax.security.auth.Subject.container"
PolicyContext has "javax.xml.soap.SOAPMessage"
PolicyContext has "org.jboss.ejb.BeanMetaData"
PolicyContext has "javax.ejb.EnterpriseBean"
Most of the keys return null, only the "javax.servlet.http.HttpServletRequest"
key returns anything.
On Logout, I find
PolicyContext has "javax.ejb.arguments"
PolicyContext has "javax.servlet.http.HttpServletRequest". It is a
org.apache.catalina.connector.RequestFacade
PolicyContext has "javax.security.auth.Subject.container". It is a
javax.security.auth.Subject
PolicyContext has "javax.xml.soap.SOAPMessage"
PolicyContext has "org.jboss.ejb.BeanMetaData"
PolicyContext has "javax.ejb.EnterpriseBean"
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3917868#3917868
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3917868
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: limitations of ClientLoginModule and security model
"[EMAIL PROTECTED]" wrote : For comparison against the cache state, the credential needs to support a java.lang.Comparable or equals(Object). THIS IS IT!!! A was bugging - and debugging my application for three days 8-P Until I added the equals(Object) method to my callback... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3917807#3917807 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3917807 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: limitations of ClientLoginModule and security model
anonymous wrote : Here's some background, in the hopes that it'll help the discussion. The U.S. Army has a centralized user database called AKO, published as an LDAP directory. We allow anyone with an AKO account to access our application. But we can't rely on this alone -- we will have many non-Army users without AKO accounts, and since we of course do not have direct control over the AKO database, we have to also maintain our own database of locally-added users. | | When a user visits the login form, then, after typing in a username and password they have to specify whether they're trying to log in with a "local" account (in our local database) or an AKO account. This way we know where to look for the user's password: either in the database, or over LDAP. | | In another twist, our application is geared to allow the creation of "one-time passwords." When using a one-time password, a client can provide a key and the password rather than a username and the "real" password. | | So clearly I need to pass more information to the server-side login modules. It's my (perhaps incorrect?) understanding that ClientLoginModule (and, in turn, SecurityAssociation) only accept two strings: username and password. They take this information and store it internally so that any future RMI calls are loaded. Then JBoss' RMI code on the server side extracts the username and password, creates a UseramePasswordHandler and starts the JAAS chain. | | So, on the client side, how would I tell the JBoss client library "hey, I need to pass not only this username and this password, but also this extra third string, over to the server next time I make an RMI call?" And then how would I reconstruct that information at the server? I can suggest the following: 1) Client Login Module  totally complaint to JAAS and accept any variant of identification according your requirements. 2) You need to implement the correspondent server side module/component for this Client Login Module. This module (let's call it Identification Module) can accept you variants of identification, is possible to work with LDAP or local database, etc. The mechanism of identification  is asymmetric key exchange between your client and your server side. For example, see how the SRP login is implemented. By the end of identification, your will have the unique session key on both client and server sides. This session key will play the role of private credentials for the given user for this particular session. This session key (together with user identity) will be put by the Client Login Module to the JBoss SecurityAssociation. 3) When your client application is performing any business call (under security domain), this information (user identity and session key) is automatically added. 4) The security interceptor on the server side gets this security information and asks JAASSecurityManager for authentication and authorisation. During these processes the JAASSecurityManager tries to find correspondent information in his security cache. Suppose, there is no such information (this call is the first). So, the server side JAAS procedure is started. 5) You have to implement server side login module, which will collaborate with the Identification Module, which has been implemented by you too, and now keeps the correspondent user identity and session key. So, during server side JAAS you login module will also be asked for authentication. After the successful authentication, the user identity, session key and the list of user roles are put into the security cache (in order to improve performance). 6) After the a12n the authorisation is being passed. Security interceptor fetches the list of roles for the given method call from the container and passes it to the JAASSecurityManager. The last one intercept the provided set of roles, with the set of user's roles from the security cache. If this set interception is not empty, the a11n is passed. Sorry, it is not possible to provide more details in the forum. Scott, please, correct me if I wrote something wrong. Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3841030#3841030 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3841030 --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: limitations of ClientLoginModule and security model
The security layer accepts a Principal and Object. The Object can contain any security context your login module can handle. For comparison against the cache state, the credential needs to support a java.lang.Comparable or equals(Object). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3840993#3840993 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3840993 --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: limitations of ClientLoginModule and security model
Write your own SecurityInterceptor and put it in the invoker stack. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3840990#3840990 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3840990 --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: limitations of ClientLoginModule and security model
Im totally with you on this one and im trying to work out exactly where the problem
is. Is it JBoss specific or is it a limitation in the J2EE specification.
Now JAAS is great total PAM based methodology allows any form of credential and
authentication credential type three phase... mutual interactive one time
token.
The problem seems to be fitting the J2EE authorisation model onto it. limitations in
having to specify a single principal, litst of roles as a policy model where JAAS
defines a much better Principal and credentials model.
Then the limitations with the SubjectSecurityManager only allowing two parameters
("username" "password"), not to mention the reauthentication of credentials (how does
this work with one time token creds??)
so it seems to me you can either ditch the policy model (web-constraints and ejb
constraints) in J2EE if you want a more complex security model and roll your own
authorisation
OR
be limited to the available security model if you want the policy model.
OR
rewrite the whole thing...
is it just JBoss? or J2EE?
is it time to think dotnot?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3840987#3840987
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3840987
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: limitations of ClientLoginModule and security model
"[EMAIL PROTECTED]" wrote : If you don't want the use the embedded NameCallback, PasswordCallback of the ClientLoginModule you chain it with an login module that provides the correct Principal and credentidal. You then specify the password-stacking="useFirstPass" option to indicate that the credentials to pass come from the first login module: Thank you both for the kind replies. But I'm not sure I understand. Scott, it seems that your solution works well on the client side. But as I understand it, the client's JAAS context is entirely decoupled from the server-side context that JBoss uses to authenticate EJB calls. What I'm most concerned with is what happens on the server side. Here's some background, in the hopes that it'll help the discussion. The U.S. Army has a centralized user database called AKO, published as an LDAP directory. We allow anyone with an AKO account to access our application. But we can't rely on this alone -- we will have many non-Army users without AKO accounts, and since we of course do not have direct control over the AKO database, we have to also maintain our own database of locally-added users. When a user visits the login form, then, after typing in a username and password they have to specify whether they're trying to log in with a "local" account (in our local database) or an AKO account. This way we know where to look for the user's password: either in the database, or over LDAP. In another twist, our application is geared to allow the creation of "one-time passwords." When using a one-time password, a client can provide a key and the password rather than a username and the "real" password. So clearly I need to pass more information to the server-side login modules. It's my (perhaps incorrect?) understanding that ClientLoginModule (and, in turn, SecurityAssociation) only accept two strings: username and password. They take this information and store it internally so that any future RMI calls are loaded. Then JBoss' RMI code on the server side extracts the username and password, creates a UseramePasswordHandler and starts the JAAS chain. So, on the client side, how would I tell the JBoss client library "hey, I need to pass not only this username and this password, but also this extra third string, over to the server next time I make an RMI call?" And then how would I reconstruct that information at the server? (I'm aware that many people have misgivings about the U.S. military. Please accept my assurances that this project is utterly peaceful in nature, related to infrastructure development rather than combat.) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3840986#3840986 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3840986 --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: limitations of ClientLoginModule and security model
If you don't want the use the embedded NameCallback, PasswordCallback of the
ClientLoginModule you chain it with an login module that provides the correct
Principal and credentidal. You then specify the password-stacking="useFirstPass"
option to indicate that the credentials to pass come from the first login module:
| srp-client {
|// Example client auth.conf for using the SRPLoginModule
|org.jboss.security.srp.jaas.SRPLoginModule required
|password-stacking="useFirstPass"
|principalClassName="org.jboss.security.SimplePrincipal"
|srpServerJndiName="SRPServerInterface"
|debug=true
|;
|
|// jBoss LoginModule
|org.jboss.security.ClientLoginModule required
|password-stacking="useFirstPass"
|;
|
|// Put your login modules that need jBoss here
| };
|
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3840971#3840971
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3840971
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: limitations of ClientLoginModule and security model
"danorris" wrote : The first is about ClientLoginModule and the underlying security classes. It seems these classes are hard-coded to use NameCallback and PasswordCallback to extract the username/password. These are somehow sent to JBoss, which reconstructs a UsernamePasswordHandler object which it passes to the login modules. | | It seems to me that this is a serious limitation. A username string and password string are not enough for some applications (like mine). My life would be much easier if I were able to define my own callback handler class, implement Serializable, and have ClientLoginModule send it over to the server without modification. | | Is anything like this possible in the 4.0 development branch? If not, are there any plans for this kind of thing in the future? Am I missing some fundamental alternate way of doing this? | I am not sure, but I think that: In the JAAS you are able to have a stack of Login Modules. Each of them provide authentication to the given user, and add some information to the single Subject (principal, credentials, etc.). The JBoss Login Module can do nothing except making special classes which will be used for adding security information to each call from client to server. It means that real JAAS identification is up to you, and use any credentials you would like. More over, the credentials, which are transferred with each client-server call could be completely different - for example it could be some unique session key, which has been generated during your identification... So, please, reread chapter 8 of the "JBoss Administration and Development" book "danorris" wrote : My second question probably stems from a lack of knowledge of the J2EE declarative security model, so please forgive my ignorance! I have a User CMP entity bean which only exposes local interfaces. I then have an Authenticator session facade bean. The Authenticator uses run-as to gain enough privileges to access the appropriate methods of the User bean and do its magic. I'd like my JAAS login module to be able to instantiate an Authenticator bean and delegate authentication to it. | | The problem is that even when I specify unchecked permissions for the Authenticator methods in ejb-jar.xml, JBoss still seems to want an authenticated principal. It doesn't care what roles that principal have, but it needs to be authenticated with my login module, which is impossible because it's my login module that needs to access the bean! The only way I could find to allow unauthenticated access to the bean is by removing the assembly-descriptor section altogether, along with the security-domain element in jboss.xml. But of course if I do that I lose declarative security on all the other beans. | | Is there a way to do what I'm describing, without creating a separate deployment descriptor and archive just for the Authenticator bean? I am not sure that your approach is the best. I think I did not manage to understand it properly. Some genenral comments: Glossary: Identification  id11n  a process through which one ascertains the identity of another person or entity (see [TMF044]). Authentication  a12n  the establishment of the validity of the identity of a user or system requiring access (see [ISO 7498-2], [TMF044]). Authorization  a11n  the granting of rights, i.e., the granting of a set of functions that can be performed based on access rights. This includes the granting of access based on access rights (see [ISO 7498-2], [TMF044]). When the user is logging on through the JAAS on the client side, the id11n process is performed (from the whole application point of view). This process could be performed without running JBoss server/container, at all. At the end of this process, on the client side there is a subject with filled principal and credentials values. Using JBoss client login module means that the correspondent information will be added to the SecurityAssociation class, which will be used for every call from the client to the server. Contrary, a12n and a11n are performed every time the call is passing the stack of interceptors (security interceptor) of the container. So, when you set the security domain in the jboss.xml file, it means that the user should be identified prior to any bean-method inside the security domain. Therefore, there should be implemented some identification mechanism, which does not touch the container security domain. For example, you can have unchecked identification bean out of scope of the security domain, or you can use external LDAP for this purpose, or something else. Sorry I am not able to write more details, because our conversation is too general. Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3840923#3840923 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3840923 -
