Well, thanks a bunch JBoss gurus! (Not you elponderador, the developers who
should know this, and should have helped!)
After much searching, I randomly stumbled across the correct incantation:
in jboss-web.xml
| jboss-web
|!-- Specify the security domain for
Adding
public Principal authenticate(Header[] headers, Map data);
To the Realm interface? Sounds good. How (under JBoss) would I instruct the
embedded Tomcat to use my user-written Realm Object just for one webapp?
Would you then also add new javax.security.auth.callback.Callback
Also, how does one log out?
After using the container's authentication to call through to my LoginModule,
my web app's logout processing then doesn't have access to the LoginContext to
call the logout() method.
I suppose my LoginModule can put it into my user principal during login
DOH!
Solved!
http://wiki.jboss.org/wiki/Wiki.jsp?page=AccessingServletRequestForAuthentication
How come nobody, not even the JBoss staff knew this unlikely-looking
incantation?
If this is a standard part of a JACC-conforming container, then this gem of
information should be made extremely
Well, there's still the problem if the web app not having access to the
LoginContext created by the container's authentication process so that it can
explicitly log out.
This is another glaring omission for which there must be a solution somewhere.
How does anyone ever log out of JAAS-secured
Nigel,
To logout, just invalidate the session. Every request the user is logged in and
logged out, that is why they cache the credentials.
request.getSession().invalidate();
If you invalidate your session, the security associations will get disconnected
from the client and then they will be
That doesn't work.
I have debug statements in my LoginModule's logout() method, and they are not
being executed.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3913564#3913564
Reply to the post :
NigelWhite wrote : That doesn't work.
|
| I have debug statements in my LoginModule's logout() method, and they are
not being executed.
Well, it will only happen on the first request. The following requests they are
just semi-authenticated (credential caching compared to provided data) and
You're saying it should call login() and then immediately logout() on the first
HTTP request??
That would be bizarre. I want to log out when then hit the logout link.
Anyway, it's not diong that - it's never getting into my LoginModule's logout()
method.
The login() is being called
OK, that won't work.
Any other ideas?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3913395#3913395
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3913395
---
This
Your frustrations are overlapping with the current focus in the Security Arena
at JBoss. In addition, to the link Brian provided, an area that fits your
needs are:
http://www.jboss.com/index.html?module=bbop=viewtopict=73024
Unless the AuthenticatorBase is retrofitted, you will not achieve
Yes, I just started a thread about this.
I'm amazed that there's no standard J2EE way to provide your own
authentication.
I would have thought that JBoss might provide a way for you to supply your I
just found http://jcp.org/en/jsr/detail?id=196 but that's just at the review
stage.
Do any
In fact, it gets worse.
To perform the athentication, I need parameters from the original URL.
The client will go to
http://foo.com/myapp/index.jsp?cic=IBMsrv=bigblueport=2332
(or sometyhing similar)
And the authentication needs the cic as the company code, and the srv and
port (as host name
It looks like we should be able to do this by using a custom Tomcat
authenticator.
I'd probably extend org.jboss.web.tomcat.security.AuthenticatorBase to make use
of its existing logic, but override
public boolean authenticate(Request request, Response response, LoginConfig
config) throws
A quick and dirty way I've seen this kind of thing done with web app FORM
authentication is to have javascript concat the access code and DOB together
and send them as the j_password. Then your login module would parse them out.
View the original post :
Good idea. It is something we had considered, but considering browser problems
with javascript, its not a very attractive one. so are you really saying,
there is no other, more standard way to do this?
View the original post :
I'm not aware of any standard way to do this, although I'm not fully up to
speed on what all the security guys have been up to in terms of providing
security hooks in the web tier (I'm in clustering). So, don't take my response
as meaning there's no way (but I doubt it).
See
17 matches
Mail list logo
