[JBoss-user] [Security & JAAS/JBoss] - Re: JaasSecurityManager ? DefaultCacheTimeout property quest
Thank you. Now it is clear that there is no defect there. Is it possible to configure the alternative behavior without code writing? Or that is the simplest way to get the behavior like in http session timeout (if this solution is not covered by some patent)? Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3863080#3863080 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3863080 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: Fundamental performance problem with JaasSecurityManager
The updated reference to this defect is: http://jira.jboss.com/jira/browse/JBAS-977 Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3863078#3863078 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3863078 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - JaasSecurityManager ? DefaultCacheTimeout property question
I have some doubts in proper interpretation of the DefaultCacheTimeout property
of the JaasSecurityManager. At first I thought that this value means the time
in the seconds during which the caller's credentials after successful logon are
being kept in the security cache and treated as valid. In addition, this
counter begins from zero any time the caller makes the successful call to the
resource in the security domain (so, this mechanism works as ?desktop
screensaver? - you don't know about it until you don't touch the keyboard or
mouse for the predefined time period). But after some experiments I found that
the last is not true (JBoss 3.2.6). The ?DefaultCacheTimeout? timeout means the
duration of life of caller's credentials in the security cache beginning from
the successful logon, without any updates. The ?stack? of the call can be
described in the following way:
JaasSecurityManager.java file, lines 236 ? 241
|public synchronized boolean isValid(Principal principal, Object
credential,
| Subject activeSubject)
|{
| // Check the cache first
| DomainInfo cacheInfo = getCacheInfo(principal, true);
|
this method is called any time the business call is being passed through the
security interceptor (and if the JaasSecurityManager is used). The ?true? value
in the getCacheInfo method means that the correspondent entity should be
flushed if it is expired.
But what about update? Or refresh the time marking?
The implementation of this method is below - JaasSecurityManager, lines 556 ?
571 (the domainCache is an instance of the TimedCachePolicy class, and the
DomainInfo implements TimedCachePolicy.TimedEntry interface):
|private DomainInfo getCacheInfo(Principal principal, boolean
allowRefresh)
|{
| if( domainCache == null )
| return null;
|
| DomainInfo cacheInfo = null;
| synchronized( domainCache )
| {
| if( allowRefresh == true )
| cacheInfo = (DomainInfo) domainCache.get(principal);
| else
| cacheInfo = (DomainInfo) domainCache.peek(principal);
| }
| return cacheInfo;
|}
|
domainCache.get is implemented in the TimedCachePolicy class, lines 156 ? 174:
|public Object get(Object key)
|{
| TimedEntry entry = (TimedEntry) entryMap.get(key);
| if( entry == null )
| return null;
|
| if( entry.isCurrent(now) == false )
| { // Try to refresh the entry
| if( entry.refresh() == false )
| { // Failed, remove the entry and return null
| entry.destroy();
| entryMap.remove(key);
| return null;
| }
| }
| Object value = entry.getValue();
| return value;
|}
|
and entry.refresh() in this case is implemented in DomainInfo class
(JaasSecurityManager.java file, lines 75 ? 79:
| public boolean refresh()
| {
| return false;
| }
|
so ? no any update.
May be the lifetime should be kept in the cache entry too, and the expiration
time should be increased in refresh method?
Best regards,
Alexander
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3863076#3863076
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3863076
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Persistence & CMP/JBoss] - Re: mysql-ds.xml deployment
Hello. I am not sure in your driver-class. Are you sure, that com.mysql.jdbc.Driver is correct? May be - "org.gjt.mm.mysql.Driver"? Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3859282#3859282 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3859282 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: I want to secure my EJB components used by remote machin
Hello. Ability to get access to the JNDI tree does not mean, that your client application has pass the JAAS login (and Subject and SecurityAssociation are set correctly). The exception you receive (most probably) means that your client application does not pass the JAAS login to the security domain. Min-chang Cha wrote : How can I solve this problem? explicitly login to the server security domain by using JAAS look into documentationhttp://www.jboss.org/wiki/Wiki.jsp?page=JBossSX Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3859234#3859234 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3859234 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: Fundamental performance problem with JaasSecurityManager
Hi.
Sorry, may be I missed something. Was this issue resolved (I did not manage to
find this item <376687> in the list)?
In addition, I did not catch the idea of the following method (version 3.2.6)
org.jboss.security.plugins.JaasSecurityManager
lines 114-121:
/** Get the currently authenticated Subject in securityDomain.
@return The Subject for securityDomain if one exists, false otherwise.
*/
public static Subject getActiveSubject(String securityDomain)
{
Subject subject = null;
return subject;
}
Sorry, for stupid questions - where should I "dig"?
Alexander
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3859014#3859014
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3859014
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: I want to secure my EJB components used by remote machin
Hello.
my personal opinion:
>From the position of the bean provider ("application component provider"), and
>forgetting about instance-based access control, you should (in general case):
1) extract the list of all use cases, where you beans are going to be used;
2) generalize the list of correspondent actors to the set of roles;
3) use these roles for setting permissions of beans/methods in ejb-jar.xml
deployment descriptor;
4) optionally, you can use this roles inside bean methods code for security or
other goals.
>From the position of ASP ("application assembler" and "application deployer")
>you should (in general case):
1) configure application server security infrastructure according your
requirements;
2) map roles from the ejb-jar.xml to real roles in the security domain of the
application server, and put this mapping information into the jboss.xml
deployment descriptor;
3) compose components to application;
4) deploy and test the application;
5) ... etc.
Alexander
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3859002#3859002
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3859002
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: Passing login failure cause to the client side
You have to parse the stack of incoming exceptions, beggining with the remote exception. In addition you can substitute the default security interceptor with your own, which will throw more detailed exceptions... Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3858518#3858518 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3858518 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: Client side security interceptor
Thank you. I'll try to use it. Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3857481#3857481 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3857481 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: Client side security interceptor
Thank you. This workaround looks interesting. And acceptable for swing client application. But, I think, the extensibility of this solution looks poor. Does JBoss have any plans/ideas to develop client container? Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3856813#3856813 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3856813 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: Adding users with Jboss API
Flushing cache will lead client to re-login. So, the client application should correctly handle the situation, when during any business call it can get the request for re-authentication. Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3856810#3856810 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3856810 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: windows NT authentication
RMI protocol is pure stateless. It means that every remote call should contain some additional information about the caller and its credentials, if we would like to support authentication and authorization on the server side. By using this information, the server side security interceptor and server side security manager provide authentication (comparing the income actual caller/credential information with the correspondent information from the internal cache), and authorization (comparing acceptable roles for caller and for remote method, which is being called). In case, the internal cache does not contain the data for actual caller, the server side Login Module is asked for desired information. So, during the authentication (in common sense) it is necessary to provide caller credentials to Login Module (or place, from which this Login Module will fetch this information). In order to do it, and avoid transferring the actual password value on the wire, you can use some kind of asymmetric key exchange protocol (SRP for example). It means that your client side login module (complaint to JAAS ) will communicate to some server side component (for example JBoss service, or something else) and perform this work. By the end of this process, both sides will hold a unique session key (this caller private credentials), which are actual only until the caller session is alive. This is similar to login to windows domain, when you get some key, which is actual until you logout, or shut down your host, or something like that. This session key will be transferred by every call from client to server and used for authentication purposes, as I described in the first paragraph. It does not mean however, that the data, which is transferred on the wire is encrypted. So, somebody could hack/debug the invocation (in theory), extract the session key, end use it maliciously for for sending his own commands to the server. This could continue until this session is not void. In addition, authorization is not bypassed in any case. Returning to you case: > I am a little puzzled by your comment on the ?not really secure?. I think that in this context it means that the RMI call is not encrypted. You can do it by yourself, or use third party ?tool? (which is preferable, I think), like SSL. > - If I understand correctly something like Kerberos, the authentication > process is secure without requiring an encrypted channel. What I mean is that > someone can not pretend to be someone else without knowing its credentials, > and you cannot determine the client credential by watching the data exchanged > on the wire. Yes. But only during the authentication process. After the end of this process, during the ordinary work it is possible to intercept the ?session key? and use it for you own goals. > - After the authentication process, I agree that without a secure channel, > someone can see (and potentially alter) the data being transferred. But this > is a different ?issue? and SSL is the answer if you want data privacy on the > wire. I think yes. > - Final possible risk that I see is, since the channel is not secure, someone > can see the data being exchanged and manage to impersonate the client (create > other messages for the server making it believe that it is the original > client). If such risk exists, could we imagine just ?signing? the message > instead of completely encrypting it? This should hopefully still be faster > than full SSL, shouldn't it? I think it will be faster. But the message is ?signed? in any cases (caller/credentials information is added to every invocation). So, such signing will not prevent impersonating the original client. > But GSS-API with Kerberos and the corresponding Login module seems to be able > to provide a few nice things: >- Single sign-on capabilities. The credentials of the user running the client >process can be ?automatically? used to authenticate against the server without >having to re-enter user/password. I am not sure that I understood this point. I think that SSO capabilities are something from different area. If you are speaking about using windows domain user credentials, I think that the SSO (in your meaning) could be achieved (the client side JAAS login module will use windows domain session key/ticket, the server side login module will validate it against windows domain controller during the first authentication, use this ticket from it's own cache on the further calls authentication). But how GSS-API with Kerberos corresponds to it? > - In such single sign-on context the password of the user is not transmitted > on the wire (only a ticket is), so it is already more secure than any other > solution that do not use an encrypted channel. No, it is not so. It is not more secure then any other solution. There are a lot of other mechanisms based on the similar algorithms (and SRP is an example of it). > - If you want bullet
[JBoss-user] [Security & JAAS/JBoss] - Client side security interceptor
Hello. I know that it is possible to configure the client side application interceptors in the jboss.xml (for example) file of the server side component. This configuration is based on the invoker type. But it means, that every client application is to use the same interceptor. Is there any way to configure a stack of client side interceptors (I need to substitute the client side security interceptors for swing based applications) in a different way for the same server side application/invoker. For example, I have two swing applications, which should use different client security interceptors, but connect to the same server side application. How can I configure client interceptors for these different client applications? In other words (in general) I need something like client side container, which I can configure for the particular host/application in a different way. How can I achieve it? Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3856422#3856422 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3856422 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [JCA/JBoss] - Re: network device communicate thru JCA 1.5
Your listner will get events from network element and propagate it through JCA API to container. I think this is possible implementation scenario. Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3856247#3856247 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3856247 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: SecurityProxy model unuseable where EJB shared by multip
"roxburd" wrote :
| Surely, EJBs should be application components which may be shared between
different applications - e.g. different WebApps. These different WebApps will
probably use different security-domains...
|
| For example, my EJB is used both by an administrator via a admin Web App
and regular users via a users Web App; each of these Web Apps are configured
with their own security domain. As far as I can tell, since the target EJB has
been configured ('hard-wired'?) to use a specific security domain, it then
cannot support both Web Apps - and my system design falls apart.
>From your example it is not clear, why do you need different security domains
>for simple role based access control. The J2EE security model supports your
>example as the main use case. You fix method-role association at deployment
>time (inside deployment descriptor) and have freedom in user-role associations
>at run-time. The server side security interceptor (and correspondent security
>manager) will get the set of roles, to which the method invocation is
>permitted, and will get the set of roles for the particular user, which is
>making the call. If the interception of these sets is not empty, the call is
>allowed. In other case the exception will be thrown (SecurityException in
>default security interceptor). This scenario is strait forward and the most
>often used.
I think that different security domains are aimed to cover another
requirements. In may opinion, it is better to think about them, as something
like Windows or UNIX security domain. When you are trying to get access to
another security domain, you should be authenticated separately, and your new
credentials will be kept in new security cache, etc. (even if this process is
hidden, and you are not aware about it). Scott, am I right? It means that each
call from your web application should login to EJB container (in your case)
separately and explicitly. I think it is possible, but personally I have never
done such variant, and it requires additional investigations.
Best regards,
Alexander
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3856235#3856235
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3856235
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: Automatic login timeout/expiration?
Darknight wrote : I have set DefaultCacheTimeout to 300 via JMX console I am not sure that this particular modifications, which are done through JMX console, will change the actual timeout of the security cache. Change the timeout in the xml file and restart the server. Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3855575#3855575 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3855575 --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: Automatic login timeout/expiration?
anonymous wrote : What happens is that after some time the login data seems to be lost and the client needs to re-auth, IMHO: check that the client calls the secured beans in the security domain; check periodically the contents of the security cahce through JMX console; anonymous wrote : however the way the login module works makes this impossible because it will detect that client "A" is already connected to the system, the result is that the client fails to work (remote exception). are you sure that this behavoiur is really desired from requirements? anonymous wrote : Is there some config option I can change to avoid this? Isn't the repeated access to the beans enough to avoid loosing the login (obviously it's not)? the repeated access to the beans in the security domain _should_ be enough. The default security cache timeout is half of a hour (see jboss-service.xml in conf directory). in general - more precise information is required about you case - the design, the configuration, may be exceptions stack etc. Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=386#386 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=386 --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: getCallerPrincipal() throws IllegalStateException: No se
>From my point of view: 1) getCallerPrincipal will throw an exception in case you deploy your bean outside of a security domain; 2) in case your bean is stateless session bean, the EntityContext method getCallerPrincipal is prohibited to call inside ejbCreate or ejbRemove methods (see specification) again - it is only my personal opinion, and may be it is wrong. Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3855335#3855335 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3855335 --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: When flush JAAS cache
from my point of view, the flush is needed when you would like some user to abort his current session and relogin immediately, prior to his next call to the server. Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3854029#3854029 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3854029 --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Security & JAAS/JBoss] - Re: When flush JAAS cache
never ;) flush cache against particular user means that 1) if this user has an open session, he/she should relogin prior any client-server interaction could be performed; 2) if this user has noopen session (how could he be flushed?), flushing the cache will not touch him at all. 1) create a new user don't flush 2) delete a new user don't flush, if the user has noopen session 3) change user details don't flush if the user has no open sessions (may be don't flush without any conditions) 4) change user password don't flush (in fact - up to you) and allows the logget user: 5) change their password from within a session don't flush Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3853848#3853848 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3853848 --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ 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
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
"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 -
[JBoss-user] [Security & JAAS/JBoss] - Re: how much is the overhead of EJB security permission?
- The unchecked methods will have any weight at runtime? - If my logic calls method _1() -> method _2() -> ... -> method _N() , and all the methods have security permission set, will the container verify just the first time or in each method step, there will be a significant weight on the security check? - The role check based on file properties (just for 1 or 2 single static users) is the best approach for securing EJB methods? 1) very little 2) in general each call is authorized separately 3) the overhead on caching principals, credentials and roles is very little, so it is up to you where to keep the security information Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3840919#3840919 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3840919 --- 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: Authentication in JBoss (login)
remowaller, try to use some kind of key exchange identification. For example look at SRP in JBoss. Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3837165#3837165 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3837165 --- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
