Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of mark_benussi@hotmail.com
 designates 65.54.162.76 as permitted sender)
Message-ID: <BAY108-DAV4D9EAB736DD605B3E212CF0710@phx.gbl>
From: "Mark Benussi" <mark_benussi@hotmail.com>
To: "'Tomcat Users List'" <users@tomcat.apache.org>
Subject: RE: Is it even possible to retrieve a custom user principal? (Was:
 Tomcat user principal)
Date: Tue, 18 Oct 2005 23:16:23 +0100
Message-ID: <002901c5d431$9321d080$0101a8c0@episys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <43553BBB.8090204@neurofire.com>
Thread-Index: AcXUEAlEJJeC7kkWQtyf/welPWYZywAIEW4A

Oh dear. Now you're asking my friend.

You are now going to have highlighted to you my ignorance in running my own
businesses and learning as I go along.

I 'think' you mean with the Container Managed Security stuff like defining
roles and paths that are locked down in your web.xml? I can't say for sure
but I think it might not work.

The reason I don't know is because I use Struts which has a little bit of an
extended/improved method (IMHO!) which allows you to tie the roles required
down to actions. Then the Struts RequestProcessor effectively calls
request.isUserInRole() under the scenes (More J2EE [IMHO!]).

In answer to some of your other questions:

"I am following that you are performing your own authentication as the
result of a post from your login form."

Yes that's what the JAAS LoginModule does/should do.

"I also see that you are putting the subject into the session. I presume
this is so you can retrieve not only your user principal, but role
principals as well for authorization."

Yup you effectively get returned the Principal that JAAS "should" put in the
session.

-----Original Message-----
From: Brad O'Hearne [mailto:brado@neurofire.com] 
Sent: 18 October 2005 19:15
To: Tomcat Users List; Mark Benussi
Subject: Re: Is it even possible to retrieve a custom user principal? (Was:
Tomcat user principal)

Mark,

Thanks so much for your help. That is very enlightening, and I'll 
consider doing the same, depending on whether I get a response about 
this from my post on the Tomcat dev mailing list. One complication of 
mine is that I've implemented single-signon, and need that behavior as 
well. I have a couple of responses (and one important question) below.

Mark Benussi wrote:

>Brad,
>
>>From my understanding of j_security_check (Which I used to use) it
>integrated seamlessly with JAAS. However:
>
>1) You will not be able to get at the Principal to place in the session if
>you let Tomcat do the work. It will still fail in the way it is doing at
the
>moment i.e. JAAS works but the request.getUserPrincipal() is not your class
>and its associated Roles.
>  
>
Ok, this is consistent with the behavior I am seeing. JAAS is working on 
my end, but I can't get at my user principal at all. This seems very 
bizarre to me. It defeats a major purpose of implementing (and then 
being required to specify in the server.xml's realm configuration) a 
custom user principal. More than that, it would be weird to have lack of 
complete support of JAAS, which is *the* authentication/authorization 
API for the Java platform, be a security deal-killer for using Tomcat.

>2) The j_security_check is a very basic validation. It doesn't really help
>if you want to let them know that the user name was ok but the password was
>wrong or that the user_name doesn't exists, which is why I write a custom
>call to JAAS via the LoginContext. See
>
><snip>
>  
>
>>    if (le instanceof UnknownUserNameException) {
>>        throw (UnknownUserNameException) le;
>>    } else if (le instanceof UserPasswordException) {
>>        throw (UserPasswordException) le;
>>    } else {
>>        throw new SystemException(le);
>>    }
>>    
>>
></snip>
>
I am following that you are performing your own authentication as the result
of a post from your login form. I also see that you are putting the subject
into the session. I presume this is so you can retrieve not only your user
principal, but role principals as well for authorization. Correct me if I am
wrong, but doesn't going this route prevent you from using *any*
container-managed security? 

Thanks again for your help. If you could answer this one last question, that
would be great!

Brad

>I get a bit scared of making these sweeping statements as there are people
>on this list that know infinitely more than me but myself and people like
>Wendy Smoak went through this a while back and when I published my thoughts
>I didn't get any grumbles.
>
>Hell maybe Apache have reworked this.
>
>
>-----Original Message-----
>From: Brad O'Hearne [mailto:brado@neurofire.com] 
>Sent: 18 October 2005 15:31
>To: Tomcat Users List
>Subject: Re: Is it even possible to retrieve a custom user principal? (Was:
>Tomcat user principal)
>
>Mark,
>
>Thanks for the response. In the code below, are you manually calling  
>JAAS, rather than via the j_security_check mechanism? The proper way  
>to access the authentication mechanism in Tomcat is to post to  
>j_security_check from a login form -- I wasn't sure from your post  
>below whether you were referring to this or to executing the below  
>code within a servlet.
>
>In my case, I'm JAAS is being invoked as a result of posting to  
>j_security_check. This is why I'm confused as to the "place the JAAS  
>subject in the session" part of it. I could just be missing the boat,  
>but I do not see that I have access to the session in my JAAS login  
>module. If you know of a way to access the session from within a JAAS  
>login module, that is the code I need to see. I should have been more  
>clear about this before.
>
>Thanks for your help Mark.
>
>Brad
>
>On Oct 18, 2005, at 1:30 AM, Mark Benussi wrote:
>
>  
>
>>Hate publishing my code.
>>
>>I have a struts form that takes the user name and password.
>>
>>// Create a new CallbackHandler
>>JAASCallbackHandler callbackHandler = new JAASCallbackHandler 
>>("username",
>>"password");
>>
>>Subject jaasSubject = null;
>>LoginContext context = null;
>>try {
>>    context = new LoginContext("IBTJAAS", callbackHandler);
>>    context.login();
>>    // Retrieve the authenticated subject
>>    jaasSubject = context.getSubject();
>>} catch (LoginException le) {
>>    if (le instanceof UnknownUserNameException) {
>>        throw (UnknownUserNameException) le;
>>    } else if (le instanceof UserPasswordException) {
>>        throw (UserPasswordException) le;
>>    } else {
>>        throw new SystemException(le);
>>    }
>>}
>>// Now place the JAAS subject in the session.
>>
>>-----Original Message-----
>>From: Brad O'Hearne [mailto:brado@neurofire.com]
>>Sent: 17 October 2005 23:06
>>To: Tomcat Users List
>>Subject: Re: Is it even possible to retrieve a custom user  
>>principal? (Was:
>>Tomcat user principal)
>>
>>Mark,
>>
>>Thanks a ton for the reply. I almost want to reply with "you're  
>>kidding,
>>right?", as I am kind of speechless that using JAAS (which I am), the
>>Java platform's standard authentication/authorization API, doesn't  
>>allow
>>one to use a custom principal. It seems like a major hole in Tomcat
>>security flexibility. I suppose I'll float on over the developer  
>>list to
>>find out more about whether this is a planned change or not, and how
>>much trouble it would be to add it.
>>
>>As for your workaround, where can I set the session? My JAAS login
>>module doesn't have access to the session, I don't believe, which is
>>where my user principal is created. If I had my principal in the
>>session, then the default isUserInRole() should work as is, I'll just
>>retrieve my custom user principal out of the session for other  
>>custom data.
>>
>>Mark, where can I add my user principal to the session?
>>
>>Brad
>>
>>Mark Benussi wrote:
>>
>>
>>    
>>
>>>If you're implementing JAAS... no. No idea about the rest. Its not
>>>
>>>      
>>>
>>supported
>>
>>    
>>
>>>in Tomcat (But should be). Stick it in the session, and then you  
>>>have to
>>>override the Tomcat HttpRequestProcessor (isUserInRole()) to get your
>>>Principal out of the session and call the validation.
>>>
>>>-----Original Message-----
>>>From: Brad O'Hearne [mailto:brado@neurofire.com]
>>>Sent: 17 October 2005 22:25
>>>To: Brad O'Hearne
>>>Cc: Tomcat Users List
>>>Subject: Is it even possible to retrieve a custom user principal?  
>>>(Was:
>>>Tomcat user principal)
>>>
>>>Hello,
>>>
>>>As this has become a bit of a roadblock in implementing security, I'd
>>>like to ask anyone out there two things:
>>>
>>>1) Is it even possible to use a custom user princpal within a  
>>>realm that
>>>is retrievable within a servlet (via presumably the request or
>>>otherwise) in Tomcat?
>>>
>>>2) If the answer to #1 is yes, how is this done? Does anyone have a
>>>working code snippet that demonstrates this?
>>>
>>>Thanks, I'm about to head to the developer list to ask this  
>>>question, as
>>>its pretty crucial for our security implementation.
>>>
>>>Brad
>>>
>>>Brad O'Hearne wrote:
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Response below:
>>>>
>>>>Wendy Smoak wrote:
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>From: "Brad O'Hearne" <brado@neurofire.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>I would have expected that designation of the user class name  
>>>>>>would
>>>>>>have resulted in my being returned the class I specified for the
>>>>>>user class name from the requestion.getUserPrincpal() method,  
>>>>>>but it
>>>>>>doesn't.
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>What version of Tomcat are you using?  As far as I know, it  
>>>>>works the
>>>>>way you want on 5.0.28.  I remember trying it with and without the
>>>>>class name, and writing that comment to remind myself.
>>>>>
>>>>>Could this be it?
>>>>>http://issues.apache.org/bugzilla/show_bug.cgi?id=37044
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>I am using 5.0.28, and I'm not seeing the expected behavior.
>>>>Hmmm.....was there anything else that has to be done to be able to
>>>>access your own custom user principal?
>>>>
>>>>Brad
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org