Ok in this case you have no choice but to go the Tomcat Valve/Custom
Authenticator route.
Sohil - thanks very much for suggesting this! I've successfully implemented a
custom Tomcat Authenticator/Value, and that solves the problem, and I've been
able to achieve exactly what I wanted.
Sohil,
You said...
anonymous wrote :
|
| why can't you re-use JBoss Portal's JAAS mechanism and just plug in your
own LoginModule for your application specific authentication logic?
|
|
I would LOVE to know how to do this...
Is there a wiki reference or somewhere you can point me?
[EMAIL PROTECTED] wrote : to integrate with the JAAS security realm, your
best bet/cleanest solution would be to write your own Tomcat Authenticator
(which is actually a form of Tomcat Valve)
|
| Authenticators are actually pretty simple in tomcat and best source of How
To is the tomcat
Indy-
Here is some information related Portal Login Modules
http://docs.jboss.com/jbportal/v2.6/referenceGuide/html/authentication.html
Thanks
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4071624#4071624
Reply to the post :
krish-
anonymous wrote :
| I have a servlet implemented that uses the LoginContext and invokes my
security realm. It passes through the various login modules and authentication
succeeds. However, JBoss Portal throws an authorization exception as the
principals were never set.
|
Again,
Sohil,
The reason I need to use my own security realm is because this realm is shared
by more than one application and JBoss Portal is just one of the applications
deployed in JBoss that uses this shared realm.
The way I've implemented this -
* There is a shared security realm (and possibly,
I would recommend integrating with JBoss Portal's security realm with your
custom LoginModules.
What do you exactly mean by this? JBoss Portal uses a portal security realm
that uses the JBoss OOTB login modules. I've used my own security realm and
that works just fine if I use container
Yes you are correct. New security realm is not the issue. Its inability of the
Servlet Environment to properly populate the security information needed by
JBoss Portal.
In fact why dont you try swicthing the portal security realm to your
custom/shared security realm and its LoginModules. You
[EMAIL PROTECTED] wrote : Yes you are correct. New security realm is not the
issue. Its inability of the Servlet Environment to properly populate the
security information needed by JBoss Portal.
|
| In fact why dont you try swicthing the portal security realm to your
custom/shared security
Okay, one step further. This is what I need:
public boolean checkPermission(PortalPermission permission) throws
IllegalArgumentException, PortalSecurityException
|{
| try
| {
| // Get the current authenticated subject through the JACC contract
|
ah ok-
I understand your situation now.
Ok in this case you have no choice but to go the Tomcat Valve/Custom
Authenticator route.
This is the only place you can actually grab hold of the Tomcat Session and
populate it with the Subject/Principals that will be propagated through to
Portal.
..and my guess is that after the authentication happens, the PolicyContext is
set for javax.security.auth.Subject.container but this happens in a different
thread. Therefore, when I do a servlet forward, this subject is not found as
this is a new/different thread..
View the original post :
[EMAIL PROTECTED] wrote : ah ok-
|
| I understand your situation now.
|
| Ok in this case you have no choice but to go the Tomcat Valve/Custom
Authenticator route.
|
| This is the only place you can actually grab hold of the Tomcat Session and
populate it with the
Error stack:
| org.hibernate.HibernateException: Unable to locate current JTA transaction
| at
org.hibernate.context.JTASessionContext.currentSession(JTASessionContext.java:61)
| at
org.hibernate.impl.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:542)
| at
kpalania-
You need to call this in the context of an active Transaction
Thanks
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4071350#4071350
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4071350
forgot somthing
portlet-nameUserManagerPortlet/portlet-name
trans-attributeRequired/trans-attribute
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4071352#4071352
Reply to the post :
Thanks folks, but I am not making this call in a portlet. I am trying to
authenticate the user WITHOUT using the Out-of-the-box FORM-based
authentication and as part of these changes, I've disabled FORM-based
authentication, created a new servlet that does the authentication and a
redirect
ok, i think i found it. i am doing it programmatically using the
JBossTransactionManagerLookup.getTransactionManager() API.
While this works, and I am able to explicitly set the portal.principal
session attribute to a HashMap that contains the Portal User object, I am still
not able to get
kpalania-
UserModule needs to be called within the context of an already active
Transaction.
Try something like this:
| SessionFactory identitySessionFactory = (SessionFactory)new
InitialContext().lookup(java:/portal/IdentitySessionFactory);
| Session session =
Thanks Sohil. Yes, this is exactly what I am doing (I also tried using the
JBoss TransactionManager class directly, and that worked too). Now, I am able
to explicitly set the portal.principal session attribute to this user but
like I mentioned earlier, it still doesn't help.
The principals are
krish-
JBoss Portal relies on JAAS/Tomcat integration for setting up the Portal
security Subjects.
So in your case I would recommend using a Tomcat Valve to process your
authentication and set up the Subjects the way JAAS does it inside Tomcat.
There is a fair bit of hacking involved here.
So in your case I would recommend using a Tomcat Valve to process your
authentication and set up the Subjects the way JAAS does it inside Tomcat.
Is this my ONLY option? I am not familiar with either how Tomcat valves work,
or how subjects are set inside Tomcat, so it might be a little painful
If there is a simple way to move away from container managed FORM-based
authentication for JBoss Portal and invoke the security realm explicitly,
keeping everything else the same, that would work perfect for me.
View the original post :
to integrate with the JAAS security realm, your best bet/cleanest solution
would be to write your own Tomcat Authenticator (which is actually a form of
Tomcat Valve)
Authenticators are actually pretty simple in tomcat and best source of How To
is the tomcat source code and see how the existing
24 matches
Mail list logo