Scott,
Thanks for the answer.
I agree that it is not likely that the web browser will be able to provide
custom credentials.
But I also do not think that I have to go that far as the unique id that I want
to add to the principal to make it unique could be generated right at the
tomcat/JBoss
That particular usage could probably be encapsulated into this feature request:
http://jira.jboss.com/jira/browse/JBAS-1802
A principal factory could be added so that the tomcat caching principal is
using the custom principal as the security domain principal.
View the original post :
I just tried with JBoss 4.0.2 and it is definitley working much better.
Without any changes to the configuration of the default server of JBoss 4.0.2,
I managed to do the following:
1) Create a custom login module that is creating a custom principal
2) Deploy EJB + servlet configured with the
Custom principal support did not work in 3.2.3, so you definitely need the
latter versions.
There certainly is a fundament difference between web tier and ejb tier
authentication. How likely is it that IE6.x is going to be able to provide
custom credentials for an authentication mechanism?
I never created a patch for JBoss before, but I will give it a try.
I also would like the solution to be complete and work when using a web client
going through a servlet.
Here is what I did so far:
1) Create a simple servlet that is deployed under the same JAAS security domain
as my EJBs
So your understanding of not being able to create a custom principal from the
web tier is false. Its exactly the same as the ejb case, so explain why there
is an apparent difference.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3878223#3878223
Reply to the
You are correct, I am confused.
Let's say that I have two custom login modules:
- CustomClientLoginModule: used on the EJB client side to create the custom
principal.
- CustomServerLoginModule: used on the EJB server side to perform my custom
authentication.
In an EJB client/server mode,
I did a few more tests and I think I can try to define my configuration and
question a little better:
- I have one JAAS security domain using, for example, the LDAP login module and
nothing else (not ClientLoginModule or anything like that, the
SecurityAssociationValve is the one taking care
I might have found one of the answer to my questions.
I am currently using JBoss 3.2.3 (but I am looking at JBoss 3.2.6 source code,
which might explain some of my confusion).
Anyway, in JBoss 3.2.6, it seems that there is a custom principal valve that is
supposed to be used so the principal
I believe that I have a working solution (tests seems to be conclusive).
Let me know if this makes senses.
1) Create a custom principal class holding user name and an extra id
attribute.
2) Create a custom login module for the client. This custom login module is
requesting only user name and
Yes, that seems fine. This would not take much of a customization of the
ClientLoginModule to allow for building a custom principal with info dervied
from the login module config and callback handlers to push this level of
support to the default jboss implementation. If you want to create a
No, because the cache key is the principal name. Unless the client can provide
a unqiue key the login module cannot attempt to unique it as this information
will not be available in subsequent requests. The client has to be able to
differentiate between uses of the same principal.
View the
I am not sure I understand what you mean.
For example, if I want to write a login module to have user name, password and
domain name (for windows), I probably need to write a custom login module for
both the client and server side.
In such case, I am hoping that the same user name and password
The login info is a Principal and an opaque credential. Unless the Principal
differentiates between to uses of the same login name, there is no difference.
Its up to you to make the Principal meaningful.
View the original post :
So, disable caching.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3876531#3876531
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3876531
---
This SF.Net email is
Thanks for the prompt answer.
I thought that disabling caching means that authentication will be done for
every EJB request (and not just between two calls to loginContext.login).
Is it not the case?
Thomas
View the original post :
Yes, that is the extreme opposite. Application triggered flushing based on
meaningful events gives you control of the what is cached.
http://wiki.jboss.org/wiki/Wiki.jsp?page=CachingLoginCredentials
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3876534#3876534
I see. Thanks for the Wiki page link.
I am still concern to rely on the client code to do the proper flushing (in my
case, I have a remote EJB application).
I guess I could flush the cache before any new call to loginContext.login, but
this will still not solve my problem of not sharing the
18 matches
Mail list logo
