You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by "Luis F. Planella Gonzalez" <lf...@gmail.com> on 2008/09/03 15:59:44 UTC
Re: TomcatSecurityService
Well... I was on a vacation and only now I'm returning to this subject...
I've commented the https://issues.apache.org/jira/browse/OPENEJB-901 JIRA
issue , but I'm also pasting here my comment:
I've attached the test-updated.war file which reproduces the problem.
I've seen the examples, but I can't get it to work, so I've attached it and
here is how to reproduce:
Just to make sure, I've downloaded a clean tomcat 6.0.18 and placed the
openejb.war on the webapps dir
Copy the attached jaas.conf file to tomcat/conf directory, and update the
catalina.sh script to include
-Djava.security.auth.login.config=$CATALINA_HOME/conf/jaas.conf
Deploy the test-updated.war and run the server
Then, navigate to the root of /test-updated and click on the Servlet link
On the login prompt, any username / password is validated and granted the
role 'user'
You'll get a Permission Denied message, as well as the result for the
EJB.isCallerInRole("user")=false and the Request.isUserInRole("user")=true
What is wrong here?
--
View this message in context: http://www.nabble.com/TomcatSecurityService-tp19093534p19289830.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: TomcatSecurityService
Posted by Luis Fernando Planella Gonzalez <lf...@gmail.com>.
Yes, it has fixed my problem.
The issue https://issues.apache.org/jira/browse/OPENEJB-901 can be marked as
fixed.
Thanks.
--
Luis Fernando Planella Gonzalez
2008/9/11 Dain Sundstrom <da...@iq80.com>
> I changed the code to use getPrincipal() and everything else still works.
> Can you verify that this resolves the issue you were having with the
> JAASRelam?
>
> -dain
>
>
> On Sep 10, 2008, at 1:13 PM, Dain Sundstrom wrote:
>
> I'll try changing the code to use request.getPrincipal() and see what
>> happens.
>>
>> -dain
>>
>> On Sep 9, 2008, at 8:04 AM, Luis Fernando Planella Gonzalez wrote:
>>
>> Just to point out why Dain's example works:
>>> The CustomRealm creates a GenericPrincipal without specifying the
>>> userPrincipal constructor argument. This maks the
>>> GenericPrincipal.getUserPrincipal() method return the GenericPrincipal
>>> itself.
>>> My problem is that JAASRealm always constructs a GenericPrincipal
>>> specifying
>>> the userPrincipal argument...
>>> So, I'll just emphatize what I said in my last post: invoking
>>> request.getPrincipal() instead of request.getUserPrincipal() in
>>> OpenEJBValve
>>> should fix it, but I don't know if there are other implications.
>>> --
>>> Luis Fernando Planella Gonzalez
>>>
>>>
>>>
>>> 2008/9/9 Luis Fernando Planella Gonzalez <lf...@gmail.com>
>>>
>>> I've tried the examples Dain attached on the jira issue and they do
>>>> work.
>>>> So, I've just decided to make my hands dirty and I've download both
>>>> tomcat
>>>> 6.0.18 and openejb 3.0 source code.
>>>>
>>>> To me, the key point seems the class
>>>> org.apache.catalina.realm.RealmBase,
>>>> on line 852, method hasRole(Principal, String).
>>>> It is only able to determine whether the given principal has the given
>>>> role
>>>> if the principal is an instance of
>>>> org.apache.catalina.realm.GenericPrincipal.
>>>>
>>>> My proposed solution: When OpenEJBValve invokes
>>>> TomcatSecurityService.enterWebApp() on line 41, request.getPrincipal()
>>>> should passed instead of request.getUserPrincipal(). I think it would
>>>> work,
>>>> because org.apache.catalina.connector.Request.getUserPrincipal() checks
>>>> if
>>>> principal is a GenericPrincipal, returning
>>>> GenericPrincipal.getUserPrincipal(), which leads to the problem I
>>>> related
>>>> before, of not having the GenericPrincipal itself.
>>>>
>>>> Is this an acceptable solution or it have other implications?
>>>>
>>>> --
>>>> Luis Fernando Planella Gonzalez
>>>>
>>>>
>>>>
>>>>
>>>> 2008/9/8 David Blevins <da...@visi.com>
>>>>
>>>>
>>>> On Sep 8, 2008, at 6:13 AM, Luis F. Planella Gonzalez wrote:
>>>>>
>>>>> The tomcat realm is a JAASRealm with a login module that always
>>>>> validates
>>>>>
>>>>>> the user and grants the 'user' role.
>>>>>>
>>>>>> After a successful login, on the servlet, an EJBAccessException is
>>>>>> always
>>>>>> thrown, and the weird part is that the tomcat realm (as seen on
>>>>>> request.isUserInRole('user')) is using the login information correcly,
>>>>>> but
>>>>>> the EJB is not. That's why I've reported
>>>>>> http://issues.apache.org/jira/browse/OPENEJB-902 another issue where
>>>>>> I
>>>>>> said
>>>>>> that the TomcatSecurityService should delegate the isCallerInRole() to
>>>>>> realm.hasRole(), but, as
>>>>>> http://www.nabble.com/Re%3A-TomcatSecurityService-p19125345.htmlstated
>>>>>> previously by Dain , this is done under the hood by the JACC
>>>>>> implementation.
>>>>>>
>>>>>>
>>>>> Hi Luis,
>>>>>
>>>>> Looking at Dain's response it seems like the ejb isCallerInRole
>>>>> ultimate
>>>>> does delegate to user.getRealm().hasRole(user.getTomcatPrincipal(),
>>>>> logicalRole) to determine if a user has a role. Looking at your reply
>>>>> it
>>>>> wasn't clear to me if you tried the example Dain made. Where you able
>>>>> to
>>>>> get that to work? That would help us determine where the issue might
>>>>> be.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>
>>
>
Re: TomcatSecurityService
Posted by Dain Sundstrom <da...@iq80.com>.
I changed the code to use getPrincipal() and everything else still
works. Can you verify that this resolves the issue you were having
with the JAASRelam?
-dain
On Sep 10, 2008, at 1:13 PM, Dain Sundstrom wrote:
> I'll try changing the code to use request.getPrincipal() and see
> what happens.
>
> -dain
>
> On Sep 9, 2008, at 8:04 AM, Luis Fernando Planella Gonzalez wrote:
>
>> Just to point out why Dain's example works:
>> The CustomRealm creates a GenericPrincipal without specifying the
>> userPrincipal constructor argument. This maks the
>> GenericPrincipal.getUserPrincipal() method return the
>> GenericPrincipal
>> itself.
>> My problem is that JAASRealm always constructs a GenericPrincipal
>> specifying
>> the userPrincipal argument...
>> So, I'll just emphatize what I said in my last post: invoking
>> request.getPrincipal() instead of request.getUserPrincipal() in
>> OpenEJBValve
>> should fix it, but I don't know if there are other implications.
>> --
>> Luis Fernando Planella Gonzalez
>>
>>
>>
>> 2008/9/9 Luis Fernando Planella Gonzalez <lf...@gmail.com>
>>
>>> I've tried the examples Dain attached on the jira issue and they
>>> do work.
>>> So, I've just decided to make my hands dirty and I've download
>>> both tomcat
>>> 6.0.18 and openejb 3.0 source code.
>>>
>>> To me, the key point seems the class
>>> org.apache.catalina.realm.RealmBase,
>>> on line 852, method hasRole(Principal, String).
>>> It is only able to determine whether the given principal has the
>>> given role
>>> if the principal is an instance of
>>> org.apache.catalina.realm.GenericPrincipal.
>>>
>>> My proposed solution: When OpenEJBValve invokes
>>> TomcatSecurityService.enterWebApp() on line 41,
>>> request.getPrincipal()
>>> should passed instead of request.getUserPrincipal(). I think it
>>> would work,
>>> because org.apache.catalina.connector.Request.getUserPrincipal()
>>> checks if
>>> principal is a GenericPrincipal, returning
>>> GenericPrincipal.getUserPrincipal(), which leads to the problem I
>>> related
>>> before, of not having the GenericPrincipal itself.
>>>
>>> Is this an acceptable solution or it have other implications?
>>>
>>> --
>>> Luis Fernando Planella Gonzalez
>>>
>>>
>>>
>>>
>>> 2008/9/8 David Blevins <da...@visi.com>
>>>
>>>
>>>> On Sep 8, 2008, at 6:13 AM, Luis F. Planella Gonzalez wrote:
>>>>
>>>> The tomcat realm is a JAASRealm with a login module that always
>>>> validates
>>>>> the user and grants the 'user' role.
>>>>>
>>>>> After a successful login, on the servlet, an EJBAccessException
>>>>> is always
>>>>> thrown, and the weird part is that the tomcat realm (as seen on
>>>>> request.isUserInRole('user')) is using the login information
>>>>> correcly,
>>>>> but
>>>>> the EJB is not. That's why I've reported
>>>>> http://issues.apache.org/jira/browse/OPENEJB-902 another issue
>>>>> where I
>>>>> said
>>>>> that the TomcatSecurityService should delegate the
>>>>> isCallerInRole() to
>>>>> realm.hasRole(), but, as
>>>>> http://www.nabble.com/Re%3A-TomcatSecurityService-p19125345.html
>>>>> stated
>>>>> previously by Dain , this is done under the hood by the JACC
>>>>> implementation.
>>>>>
>>>>
>>>> Hi Luis,
>>>>
>>>> Looking at Dain's response it seems like the ejb isCallerInRole
>>>> ultimate
>>>> does delegate to user.getRealm().hasRole(user.getTomcatPrincipal(),
>>>> logicalRole) to determine if a user has a role. Looking at your
>>>> reply it
>>>> wasn't clear to me if you tried the example Dain made. Where you
>>>> able to
>>>> get that to work? That would help us determine where the issue
>>>> might be.
>>>>
>>>> -David
>>>>
>>>>
>>>
>
Re: TomcatSecurityService
Posted by Dain Sundstrom <da...@iq80.com>.
I'll try changing the code to use request.getPrincipal() and see what
happens.
-dain
On Sep 9, 2008, at 8:04 AM, Luis Fernando Planella Gonzalez wrote:
> Just to point out why Dain's example works:
> The CustomRealm creates a GenericPrincipal without specifying the
> userPrincipal constructor argument. This maks the
> GenericPrincipal.getUserPrincipal() method return the GenericPrincipal
> itself.
> My problem is that JAASRealm always constructs a GenericPrincipal
> specifying
> the userPrincipal argument...
> So, I'll just emphatize what I said in my last post: invoking
> request.getPrincipal() instead of request.getUserPrincipal() in
> OpenEJBValve
> should fix it, but I don't know if there are other implications.
> --
> Luis Fernando Planella Gonzalez
>
>
>
> 2008/9/9 Luis Fernando Planella Gonzalez <lf...@gmail.com>
>
>> I've tried the examples Dain attached on the jira issue and they do
>> work.
>> So, I've just decided to make my hands dirty and I've download both
>> tomcat
>> 6.0.18 and openejb 3.0 source code.
>>
>> To me, the key point seems the class
>> org.apache.catalina.realm.RealmBase,
>> on line 852, method hasRole(Principal, String).
>> It is only able to determine whether the given principal has the
>> given role
>> if the principal is an instance of
>> org.apache.catalina.realm.GenericPrincipal.
>>
>> My proposed solution: When OpenEJBValve invokes
>> TomcatSecurityService.enterWebApp() on line 41,
>> request.getPrincipal()
>> should passed instead of request.getUserPrincipal(). I think it
>> would work,
>> because org.apache.catalina.connector.Request.getUserPrincipal()
>> checks if
>> principal is a GenericPrincipal, returning
>> GenericPrincipal.getUserPrincipal(), which leads to the problem I
>> related
>> before, of not having the GenericPrincipal itself.
>>
>> Is this an acceptable solution or it have other implications?
>>
>> --
>> Luis Fernando Planella Gonzalez
>>
>>
>>
>>
>> 2008/9/8 David Blevins <da...@visi.com>
>>
>>
>>> On Sep 8, 2008, at 6:13 AM, Luis F. Planella Gonzalez wrote:
>>>
>>> The tomcat realm is a JAASRealm with a login module that always
>>> validates
>>>> the user and grants the 'user' role.
>>>>
>>>> After a successful login, on the servlet, an EJBAccessException
>>>> is always
>>>> thrown, and the weird part is that the tomcat realm (as seen on
>>>> request.isUserInRole('user')) is using the login information
>>>> correcly,
>>>> but
>>>> the EJB is not. That's why I've reported
>>>> http://issues.apache.org/jira/browse/OPENEJB-902 another issue
>>>> where I
>>>> said
>>>> that the TomcatSecurityService should delegate the
>>>> isCallerInRole() to
>>>> realm.hasRole(), but, as
>>>> http://www.nabble.com/Re%3A-TomcatSecurityService-p19125345.html
>>>> stated
>>>> previously by Dain , this is done under the hood by the JACC
>>>> implementation.
>>>>
>>>
>>> Hi Luis,
>>>
>>> Looking at Dain's response it seems like the ejb isCallerInRole
>>> ultimate
>>> does delegate to user.getRealm().hasRole(user.getTomcatPrincipal(),
>>> logicalRole) to determine if a user has a role. Looking at your
>>> reply it
>>> wasn't clear to me if you tried the example Dain made. Where you
>>> able to
>>> get that to work? That would help us determine where the issue
>>> might be.
>>>
>>> -David
>>>
>>>
>>
Re: TomcatSecurityService
Posted by Luis Fernando Planella Gonzalez <lf...@gmail.com>.
Just to point out why Dain's example works:
The CustomRealm creates a GenericPrincipal without specifying the
userPrincipal constructor argument. This maks the
GenericPrincipal.getUserPrincipal() method return the GenericPrincipal
itself.
My problem is that JAASRealm always constructs a GenericPrincipal specifying
the userPrincipal argument...
So, I'll just emphatize what I said in my last post: invoking
request.getPrincipal() instead of request.getUserPrincipal() in OpenEJBValve
should fix it, but I don't know if there are other implications.
--
Luis Fernando Planella Gonzalez
2008/9/9 Luis Fernando Planella Gonzalez <lf...@gmail.com>
> I've tried the examples Dain attached on the jira issue and they do work.
> So, I've just decided to make my hands dirty and I've download both tomcat
> 6.0.18 and openejb 3.0 source code.
>
> To me, the key point seems the class org.apache.catalina.realm.RealmBase,
> on line 852, method hasRole(Principal, String).
> It is only able to determine whether the given principal has the given role
> if the principal is an instance of
> org.apache.catalina.realm.GenericPrincipal.
>
> My proposed solution: When OpenEJBValve invokes
> TomcatSecurityService.enterWebApp() on line 41, request.getPrincipal()
> should passed instead of request.getUserPrincipal(). I think it would work,
> because org.apache.catalina.connector.Request.getUserPrincipal() checks if
> principal is a GenericPrincipal, returning
> GenericPrincipal.getUserPrincipal(), which leads to the problem I related
> before, of not having the GenericPrincipal itself.
>
> Is this an acceptable solution or it have other implications?
>
> --
> Luis Fernando Planella Gonzalez
>
>
>
>
> 2008/9/8 David Blevins <da...@visi.com>
>
>
>> On Sep 8, 2008, at 6:13 AM, Luis F. Planella Gonzalez wrote:
>>
>> The tomcat realm is a JAASRealm with a login module that always validates
>>> the user and grants the 'user' role.
>>>
>>> After a successful login, on the servlet, an EJBAccessException is always
>>> thrown, and the weird part is that the tomcat realm (as seen on
>>> request.isUserInRole('user')) is using the login information correcly,
>>> but
>>> the EJB is not. That's why I've reported
>>> http://issues.apache.org/jira/browse/OPENEJB-902 another issue where I
>>> said
>>> that the TomcatSecurityService should delegate the isCallerInRole() to
>>> realm.hasRole(), but, as
>>> http://www.nabble.com/Re%3A-TomcatSecurityService-p19125345.html stated
>>> previously by Dain , this is done under the hood by the JACC
>>> implementation.
>>>
>>
>> Hi Luis,
>>
>> Looking at Dain's response it seems like the ejb isCallerInRole ultimate
>> does delegate to user.getRealm().hasRole(user.getTomcatPrincipal(),
>> logicalRole) to determine if a user has a role. Looking at your reply it
>> wasn't clear to me if you tried the example Dain made. Where you able to
>> get that to work? That would help us determine where the issue might be.
>>
>> -David
>>
>>
>
Re: TomcatSecurityService
Posted by Luis Fernando Planella Gonzalez <lf...@gmail.com>.
I've tried the examples Dain attached on the jira issue and they do work.
So, I've just decided to make my hands dirty and I've download both tomcat
6.0.18 and openejb 3.0 source code.
To me, the key point seems the class org.apache.catalina.realm.RealmBase, on
line 852, method hasRole(Principal, String).
It is only able to determine whether the given principal has the given role
if the principal is an instance of
org.apache.catalina.realm.GenericPrincipal.
My proposed solution: When OpenEJBValve invokes
TomcatSecurityService.enterWebApp() on line 41, request.getPrincipal()
should passed instead of request.getUserPrincipal(). I think it would work,
because org.apache.catalina.connector.Request.getUserPrincipal() checks if
principal is a GenericPrincipal, returning
GenericPrincipal.getUserPrincipal(), which leads to the problem I related
before, of not having the GenericPrincipal itself.
Is this an acceptable solution or it have other implications?
--
Luis Fernando Planella Gonzalez
2008/9/8 David Blevins <da...@visi.com>
>
> On Sep 8, 2008, at 6:13 AM, Luis F. Planella Gonzalez wrote:
>
> The tomcat realm is a JAASRealm with a login module that always validates
>> the user and grants the 'user' role.
>>
>> After a successful login, on the servlet, an EJBAccessException is always
>> thrown, and the weird part is that the tomcat realm (as seen on
>> request.isUserInRole('user')) is using the login information correcly, but
>> the EJB is not. That's why I've reported
>> http://issues.apache.org/jira/browse/OPENEJB-902 another issue where I
>> said
>> that the TomcatSecurityService should delegate the isCallerInRole() to
>> realm.hasRole(), but, as
>> http://www.nabble.com/Re%3A-TomcatSecurityService-p19125345.html stated
>> previously by Dain , this is done under the hood by the JACC
>> implementation.
>>
>
> Hi Luis,
>
> Looking at Dain's response it seems like the ejb isCallerInRole ultimate
> does delegate to user.getRealm().hasRole(user.getTomcatPrincipal(),
> logicalRole) to determine if a user has a role. Looking at your reply it
> wasn't clear to me if you tried the example Dain made. Where you able to
> get that to work? That would help us determine where the issue might be.
>
> -David
>
>
Re: TomcatSecurityService
Posted by David Blevins <da...@visi.com>.
On Sep 8, 2008, at 6:13 AM, Luis F. Planella Gonzalez wrote:
> The tomcat realm is a JAASRealm with a login module that always
> validates
> the user and grants the 'user' role.
>
> After a successful login, on the servlet, an EJBAccessException is
> always
> thrown, and the weird part is that the tomcat realm (as seen on
> request.isUserInRole('user')) is using the login information
> correcly, but
> the EJB is not. That's why I've reported
> http://issues.apache.org/jira/browse/OPENEJB-902 another issue
> where I said
> that the TomcatSecurityService should delegate the isCallerInRole() to
> realm.hasRole(), but, as
> http://www.nabble.com/Re%3A-TomcatSecurityService-p19125345.html
> stated
> previously by Dain , this is done under the hood by the JACC
> implementation.
Hi Luis,
Looking at Dain's response it seems like the ejb isCallerInRole
ultimate does delegate to
user.getRealm().hasRole(user.getTomcatPrincipal(), logicalRole) to
determine if a user has a role. Looking at your reply it wasn't clear
to me if you tried the example Dain made. Where you able to get that
to work? That would help us determine where the issue might be.
-David
Re: TomcatSecurityService
Posted by "Luis F. Planella Gonzalez" <lf...@gmail.com>.
Hi, sorry for insisting on the subject, but my deadline for security in the
project is getting close...
Can someone, please, tell me what's wrong in my code?
Here is the servlet:
public class TestServlet extends HttpServlet {
private static final long serialVersionUID = -8840939476659309738L;
@EJB
private TestService testService;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType("text/html");
resp.setCharacterEncoding("utf-8");
PrintWriter writer = resp.getWriter();
try {
writer.println(testService.sayHello(req.getParameter("name")) +
"<br>");
} catch (EJBAccessException e) {
writer.println("Permission denied<br>");
writer.println("@EJB.isUserInRole(\"user\")=" +
testService.hasUserRole() + "<br>");
writer.println("Request.isUserInRole(\"user\")=" +
req.isUserInRole("user") + "<br>");
}
resp.flushBuffer();
}
}
The EJB is as simple as:
@Stateless
@DeclareRoles("user")
public class TestServiceBean implements TestService {
@Resource
private SessionContext context;
@RolesAllowed("user")
public String sayHello(String name) {
return "Hello, " + name + ", your principal is " +
context.getCallerPrincipal().getName();
}
public boolean hasUserRole() {
return context.isCallerInRole("user");
}
}
The tomcat realm is a JAASRealm with a login module that always validates
the user and grants the 'user' role.
After a successful login, on the servlet, an EJBAccessException is always
thrown, and the weird part is that the tomcat realm (as seen on
request.isUserInRole('user')) is using the login information correcly, but
the EJB is not. That's why I've reported
http://issues.apache.org/jira/browse/OPENEJB-902 another issue where I said
that the TomcatSecurityService should delegate the isCallerInRole() to
realm.hasRole(), but, as
http://www.nabble.com/Re%3A-TomcatSecurityService-p19125345.html stated
previously by Dain , this is done under the hood by the JACC implementation.
Sorry for the long post, but this is my last attempt for a "correct"
solution for this problem, before trying something nasty...
--
View this message in context: http://www.nabble.com/TomcatSecurityService-tp19093534p19371735.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.