FAQ

[Tomcat-users] Setting JK_REMOTE_USER help

Marc Boorshtein
Jun 16, 2010 at 11:17 am
All,

I'm trying to setup apache in front of tomcat and have apache do the
authentication for access and pass the user's context back to tomcat.
I've seen documentation that says that I should set the JK_REMOTE_USER
environment variable but it doesn't seem to be working. Here is my
httpd configuration:

JkWorkerProperty worker.list=worker1
JkWorkerProperty worker.worker1.type=ajp13
JkWorkerProperty worker.worker1.host=localhost
JkWorkerProperty worker.worker1.port=8009

JkShmFile /home/sys/oracle/oaam/apache/tmp/mod_jk.shm
JkLogFile /home/sys/oracle/oaam/apache/logs/mod_jk.log
JkLogLevel debug
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
#JkEnvVar REMOTE_USER worker1
JkEnvVar JK_REMOTE_USER %{remoteUser}e
<Location /oarm/* >
AuthType Basic
AuthName "OARM - Apache"
# (Following line optional)
AuthBasicProvider file
AuthUserFile /home/sys/oracle/oaam/apache/conf/oarm.pwd
Require user oaamadmin

#SetEnv JK_REMOTE_USER REMOTE_USER
#JkEnvVar JK_REMOTE_USER %{remoteUser}e

JkMount worker1
</Location>

Any help would be greatly appreciated

Thanks

Marc

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

Search Discussions

21 responses

  • André Warnier at Jun 16, 2010 at 1:06 pm

    Marc Boorshtein wrote:
    All,

    I'm trying to setup apache in front of tomcat and have apache do the
    authentication for access and pass the user's context back to tomcat.
    I've seen documentation that says that I should set the JK_REMOTE_USER
    environment variable but it doesn't seem to be working.
    You should not need to do that, it should be automatic.
    Just make sure that in the Tomcat <Connector> for AJP (in server.xml), you set the attribute
    tomcatAuthentication="false"

    If the request is authenticated by Apache, mod_jk will (always) pass it internally to
    Tomcat, along with the request. If the above attribute is set, then Tomcat will also
    "believe" this user-id, and not try itself to authenticate the user.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • André Warnier at Jun 16, 2010 at 1:24 pm
    Also, it is *really really really* helpful, when you post a question, that you would
    specify the precise versions of software you are talking about.
    Like :
    Apache httpd version : 2.2.3
    Tomcat version : 5.5.21
    mod_jk version : 1.2.18
    .. the documentation .. : the documentation page at : http://tomcat.apache.org/.....

    It helps people here figure out if you have a real problem, or if your are using an old
    version with a know bug, or if you are looking at some incorrect instructions etc... It
    helps them getter a better idea, quickly, of where the issue may be. And it shows that
    you have at least done some homework yourself, before asking other people to spend their
    time trying to help you.
    All of the above have the indirect effect of motivating more people to help you faster, so
    it is also to your own advantage.


    André Warnier wrote:
    Marc Boorshtein wrote:
    All,

    I'm trying to setup apache in front of tomcat and have apache do the
    authentication for access and pass the user's context back to tomcat.
    I've seen documentation that says that I should set the JK_REMOTE_USER
    environment variable but it doesn't seem to be working.
    You should not need to do that, it should be automatic.
    Just make sure that in the Tomcat <Connector> for AJP (in server.xml),
    you set the attribute
    tomcatAuthentication="false"
    see here :
    http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html
    (at the end)
    (if of course you are using Tomcat 6.0)
    If the request is authenticated by Apache, mod_jk will (always) pass it
    internally to Tomcat, along with the request. If the above attribute is
    set, then Tomcat will also "believe" this user-id, and not try itself to
    authenticate the user.


    ---------------------------------------------------------------------
    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
  • Marc Boorshtein at Jun 16, 2010 at 2:07 pm

    You should not need to do that, it should be automatic.
    Just make sure that in the Tomcat <Connector> for AJP (in server.xml), you
    set the attribute
    tomcatAuthentication="false"

    If the request is authenticated by Apache, mod_jk will (always) pass it
    internally to Tomcat, along with the request.  If the above attribute is
    set, then Tomcat will also "believe" this user-id, and not try itself to
    authenticate the user.
    OK, so the good news is that setting tomcatAuthentication="false" did
    get tomcat to not prompt me for authentication. The bad news is that
    it looks like that this doesn't actually set the user's context
    because I am receiving unauthorized messages from the application
    which relies on container security. I have an LDAP realm setup, is
    there a configuration to bridge this gap? If not I THINK I can write
    a "wrapper" realm that will take the user id attribute and "fake" it.
    Any thoughts?

    As for the versions, thanks for the reminder:
    Tomcat 6.0.26
    Apache 2.2.15
    mod_jk 1.2
    CentOS 5.5



    Thanks
    Marc

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • André Warnier at Jun 16, 2010 at 2:37 pm

    Marc Boorshtein wrote:
    You should not need to do that, it should be automatic.
    Just make sure that in the Tomcat <Connector> for AJP (in server.xml), you
    set the attribute
    tomcatAuthentication="false"

    If the request is authenticated by Apache, mod_jk will (always) pass it
    internally to Tomcat, along with the request. If the above attribute is
    set, then Tomcat will also "believe" this user-id, and not try itself to
    authenticate the user.
    OK, so the good news is that setting tomcatAuthentication="false" did
    get tomcat to not prompt me for authentication. The bad news is that
    it looks like that this doesn't actually set the user's context
    it does, but maybe not with everything you were expecting
    because I am receiving unauthorized messages from the application
    which relies on container security.
    When Apache authenticates a user, it gets a user-id, like "marcb".
    That is what mod_jk passes to Tomcat, nothing else. That is one "A" of "AAA", which
    stands for Authentication, Authorization and Access-control.
    Authorization is another step, which can only be done by Tomcat in this case, because the
    concepts do not really match between Apache httpd and Tomcat (Apache has users and groups,
    Tomcat uses "roles").

    I have an LDAP realm setup, is
    there a configuration to bridge this gap? If not I THINK I can write
    a "wrapper" realm that will take the user id attribute and "fake" it.
    Any thoughts?
    Since you have Apache in front already, you could do the whole AAA under Apache, and
    remove anything you do not really need from Tomcat.
    What do you really need to know about a user at the Tomcat application level, apart from
    his user-id ?
    (Or you could do the total opposite : do the whole AAA in Tomcat)
    The whole thing is rather flexible, and what you choose to do where is very much depending
    on your circumstances.
    (Like : do all accesses to Tomcat go through Apache first ? is the link between Apache and
    Tomcat secure ? are there resources served by Apache directly, and do some of them need
    AAA ? etc..)
    As for the versions, thanks for the reminder:
    Tomcat 6.0.26
    Apache 2.2.15
    mod_jk 1.2 <== you are missing a number here, and for some things it really matters
    CentOS 5.5
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Marc Boorshtein at Jun 16, 2010 at 3:00 pm
    OK, come context first:

    What I'm trying to do is integrate a Commercial Off The Shelf (COTS)
    application that relies on container security into a Web Access
    Manager (WAM). In a typical WAM deployment there are AAA is broken up
    into multiple layers:

    Web Server - Authentication (via the WAM) and course grained
    Authorization (can the user access this app?)
    Application - Fine grained Authorization aka Entitlements (can the
    user perform task x?)

    Since the authentication is done at the web server but the
    entitlements are done by the application the web server needs to tell
    the application server who the user is and the application server then
    needs to fulfill the J2EE contract by providing information about the
    user to the application.

    In commercial application servers (Weblogic, WebSphere, JBoss) this is
    done with an agent of some kind that satisfies the application
    server's security requirements (usually by phoning home to the WAM to
    validate the request). However commercial WAM products (SiteMinder,
    OAM, etc) don't provide an "agent" for Tomcat. Given that what I'm
    working on is a POC I'm not overly concerned with security as in
    production this app will likely run on weblogic but for my purposes
    Tomcat is a better pick for now.

    That being said, the sequence of events should be:
    1. Web server authenticates the user (works)
    2. Pass the context to Tomcat (works)
    3. Tomcat calls the realm to retrieve the user information and set
    the context (doesn't presently occur)

    #3 appears to be the issue. Authenticaiton and Authorization should
    be separate steps entirely in order to satisfy the J2EE contract in an
    enterprise environment (which often involves WAMs).

    So it doesn't sound like there is a configuration way to handle this.
    I think I'll try hacking around to see if I can solve this with some
    kind of custom Realm.
    As for the versions, thanks for the reminder:
    Tomcat 6.0.26
    Apache 2.2.15
    mod_jk 1.2   <== you are missing a number here, and for some things it
    really matters
    CentOS 5.5
    mod_jk 1.2.30
    ---------------------------------------------------------------------
    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
  • David kerber at Jun 16, 2010 at 3:12 pm
    On 6/16/2010 10:58 AM, Marc Boorshtein wrote:

    ...
    That being said, the sequence of events should be:
    1. Web server authenticates the user (works)
    2. Pass the context to Tomcat (works)
    3. Tomcat calls the realm to retrieve the user information and set
    the context (doesn't presently occur)

    #3 appears to be the issue. Authenticaiton and Authorization should
    be separate steps entirely in order to satisfy the J2EE contract in an
    enterprise environment (which often involves WAMs).

    So it doesn't sound like there is a configuration way to handle this.
    I think I'll try hacking around to see if I can solve this with some
    kind of custom Realm.
    Keep in mind that Tomcat is not a full j2ee server; it's a "servlet
    container", so may not meet some of the requirements you have for your
    app if they are part of higher-level j2ee specs.

    D

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Marc Boorshtein at Jun 16, 2010 at 3:30 pm
    Sent from my iPhone
    On Jun 16, 2010, at 11:12 AM, David kerber wrote:

    On 6/16/2010 10:58 AM, Marc Boorshtein wrote:

    ...
    That being said, the sequence of events should be:
    1. Web server authenticates the user (works)
    2. Pass the context to Tomcat (works)
    3. Tomcat calls the realm to retrieve the user information and set
    the context (doesn't presently occur)

    #3 appears to be the issue. Authenticaiton and Authorization should
    be separate steps entirely in order to satisfy the J2EE contract in
    an
    enterprise environment (which often involves WAMs).

    So it doesn't sound like there is a configuration way to handle this.
    I think I'll try hacking around to see if I can solve this with some
    kind of custom Realm.
    Keep in mind that Tomcat is not a full j2ee server; it's a "servlet
    container", so may not meet some of the requirements you have for
    your app if they are part of higher-level j2ee specs.

    D
    Yes, however there are security methods in the sevrlet spec
    (getPrincip, isUserInRole). Tomcat+mod_jk should satisfy these contracts

    Thanks
    Marc


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • André Warnier at Jun 16, 2010 at 5:31 pm

    Marc Boorshtein wrote:
    OK, come context first:

    What I'm trying to do is integrate a Commercial Off The Shelf (COTS)
    application that relies on container security into a Web Access
    Manager (WAM). In a typical WAM deployment there are AAA is broken up
    into multiple layers:

    Web Server - Authentication (via the WAM) and course grained
    Authorization (can the user access this app?)
    Application - Fine grained Authorization aka Entitlements (can the
    user perform task x?)

    Since the authentication is done at the web server but the
    entitlements are done by the application the web server needs to tell
    the application server who the user is and the application server then
    needs to fulfill the J2EE contract by providing information about the
    user to the application.

    In commercial application servers (Weblogic, WebSphere, JBoss) this is
    done with an agent of some kind that satisfies the application
    server's security requirements (usually by phoning home to the WAM to
    validate the request). However commercial WAM products (SiteMinder,
    OAM, etc) don't provide an "agent" for Tomcat. Given that what I'm
    working on is a POC I'm not overly concerned with security as in
    production this app will likely run on weblogic but for my purposes
    Tomcat is a better pick for now.

    That being said, the sequence of events should be:
    1. Web server authenticates the user (works)
    2. Pass the context to Tomcat (works)
    Well, no. It passes a user-id to Tomcat.
    For Tomcat, the user-id may be part of a "context" (although I believe that for Tomcat
    also, the word "context" means "an application".)
    3. Tomcat calls the realm to retrieve the user information and set
    the context (doesn't presently occur)
    Probably, more like yes. Tomcat, as far as I know, creates a userPrincipal object, which
    contains the user-id and other information if available.
    #3 appears to be the issue. Authenticaiton and Authorization should
    be separate steps entirely in order to satisfy the J2EE contract in an
    enterprise environment (which often involves WAMs).

    So it doesn't sound like there is a configuration way to handle this.
    I think I'll try hacking around to see if I can solve this with some
    kind of custom Realm.
    To look at this from a very strict point of view, the whole area is already a bit
    stretched. Tomcat has this notion of "roles" (because the Servlet Spec has this same
    notion). But if you look at common authentication schemes, like NTLM or LDAP, they do not
    have this notion. It is possible that some authentication "Realm" (another servlet-engine
    specific use of the term) "translates" the NTLM notion of "user group" (or some LDAP
    attribute) into Tomcat's notion of "role" (and in fact they often do). But that is a
    stretch. Unavoidable, because servlet engines do not know about "user groups", but stretch
    nevertheless.

    I suppose it would be boring if everyone agreed on the same notions all the time.

    Basically, nobody stops you from retrieving some LDAP attributes of the user at the Apache
    level, and passing them over to Tomcat by adding one or more custom HTTP headers to the
    request (or a request attribute, as explained here :
    http://tomcat.apache.org/connectors-doc/reference/apache.html
    search for "JkEnvVar").
    And then at the Tomcat level, adding a servlet filter which retrieves these
    header/attributes and stuffs them inside the UserPrincipal object, to satisfy Tomcat's
    isUserInRole() call (with some approximation due to my incomplete knowledge in these matters).

    Just an idea to avoid having to access LDAP twice.




    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Marc Boorshtein at Jun 16, 2010 at 5:27 pm

    To look at this from a very strict point of view, the whole area is already
    a bit stretched.  Tomcat has this notion of "roles" (because the Servlet
    Spec has this same notion).  But if you look at common authentication
    schemes, like NTLM or LDAP, they do not have this notion.  It is possible
    that some authentication "Realm" (another servlet-engine specific use of the
    term) "translates" the NTLM notion of "user group" (or some LDAP attribute)
    into Tomcat's notion of "role" (and in fact they often do).  But that is a
    stretch. Unavoidable, because servlet engines do not know about "user
    groups", but stretch nevertheless.

    I suppose it would be boring if everyone agreed on the same notions all the
    time.
    The issue here is that the servlet specification specifies a way to
    check what "role" a user is in. How that role is implemented (LDAP
    group, user attribute, pulled out of a hat) doesn't really matter. An
    application's code can write "if (request.isUserInRole("X")..." and
    should work. It should also work whether you are using tomcat to do
    authentication or something else (ie Apache+mod_jk or federation).
    The problem with the Realm system is its designed with the assumption
    that tomcat is doing the authentication which is not a valid
    assumption in an environment where the authentication is seperated
    from authorization. The entire point of container security is that as
    a coder I don't have to worry about how any of this is implemented.


    Basically, nobody stops you from retrieving some LDAP attributes of the user
    at the Apache level, and passing them over to Tomcat by adding one or more
    custom HTTP headers to the request (or a request attribute, as explained
    here : http://tomcat.apache.org/connectors-doc/reference/apache.html
    search for "JkEnvVar").
    And then at the Tomcat level, adding a servlet filter which retrieves these
    header/attributes and stuffs them inside the UserPrincipal object, to
    satisfy Tomcat's isUserInRole() call (with some approximation due to my
    incomplete knowledge in these matters).

    Just an idea to avoid having to access LDAP twice.

    LDAP as a service is generally fast enough to be a negligable part of
    the AAA process. It looks like subclassing the JNDIRealm is going to
    be the easiest way here. I don't need perfect, just working for this
    POC. Spending 20 min on some code is still easier then getting
    weblogic up and running.

    Thanks everyone!

    Marc

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Pid at Jun 16, 2010 at 10:15 pm

    On 16/06/2010 18:27, Marc Boorshtein wrote:

    To look at this from a very strict point of view, the whole area is already
    a bit stretched. Tomcat has this notion of "roles" (because the Servlet
    Spec has this same notion). But if you look at common authentication
    schemes, like NTLM or LDAP, they do not have this notion. It is possible
    that some authentication "Realm" (another servlet-engine specific use of the
    term) "translates" the NTLM notion of "user group" (or some LDAP attribute)
    into Tomcat's notion of "role" (and in fact they often do). But that is a
    stretch. Unavoidable, because servlet engines do not know about "user
    groups", but stretch nevertheless.

    I suppose it would be boring if everyone agreed on the same notions all the
    time.
    The issue here is that the servlet specification specifies a way to
    check what "role" a user is in. How that role is implemented (LDAP
    group, user attribute, pulled out of a hat) doesn't really matter. An
    application's code can write "if (request.isUserInRole("X")..." and
    should work. It should also work whether you are using tomcat to do
    authentication or something else (ie Apache+mod_jk or federation).

    The problem with the Realm system is its designed with the assumption
    that tomcat is doing the authentication which is not a valid
    assumption in an environment where the authentication is seperated
    from authorization. The entire point of container security is that as
    a coder I don't have to worry about how any of this is implemented.
    The problem with Tomcat is that all too often it doesn't do what people
    expect it should do*.


    p

    * Or maybe the problem isn't Tomcat.
    Basically, nobody stops you from retrieving some LDAP attributes of the user
    at the Apache level, and passing them over to Tomcat by adding one or more
    custom HTTP headers to the request (or a request attribute, as explained
    here : http://tomcat.apache.org/connectors-doc/reference/apache.html
    search for "JkEnvVar").
    And then at the Tomcat level, adding a servlet filter which retrieves these
    header/attributes and stuffs them inside the UserPrincipal object, to
    satisfy Tomcat's isUserInRole() call (with some approximation due to my
    incomplete knowledge in these matters).

    Just an idea to avoid having to access LDAP twice.

    LDAP as a service is generally fast enough to be a negligable part of
    the AAA process. It looks like subclassing the JNDIRealm is going to
    be the easiest way here. I don't need perfect, just working for this
    POC. Spending 20 min on some code is still easier then getting
    weblogic up and running.

    Thanks everyone!

    Marc

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Marc Boorshtein at Jun 17, 2010 at 12:55 pm

    The problem with the Realm system is its designed with the assumption
    that tomcat is doing the authentication which is not a valid
    assumption in an environment where the authentication is seperated
    from authorization.  The entire point of container security is that as
    a coder I don't have to worry about how any of this is implemented.
    The problem with Tomcat is that all too often it doesn't do what people
    expect it should do*.


    p

    * Or maybe the problem isn't Tomcat.
    I'm not looking to start a holy war here, but is there anything
    incorrect in what I said? Tomcat is a servlet container, the servlet
    API is a contract between the container and the developer, the
    contract specifies how a developer would access role information
    regardless of the implementation. Since the Realm implementation
    assumes that Tomcat is doing the authentication and breaks when it
    isn't Tomcat, isn't that a violation of the contract? It's open
    source, so I'm not complaining or demanding anything. I think I know
    how to do what I need however that doesn't change the facts of the
    situation that Tomcat does not have the built in capability for a
    standard realm to simply retrieve user infomation as opposed to
    authentication AND user retrieval that would enable Tomcat to maintain
    its compliance while being fronted by Apache.

    Marc

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Pid at Jun 17, 2010 at 1:03 pm

    On 17/06/2010 02:41, Marc Boorshtein wrote:

    The problem with the Realm system is its designed with the assumption
    that tomcat is doing the authentication which is not a valid
    assumption in an environment where the authentication is seperated
    from authorization. The entire point of container security is that as
    a coder I don't have to worry about how any of this is implemented.
    The problem with Tomcat is that all too often it doesn't do what people
    expect it should do*.


    p

    * Or maybe the problem isn't Tomcat.
    I'm not looking to start a holy war here, but is there anything
    incorrect in what I said? Tomcat is a servlet container, the servlet
    Yes.

    You made a sweeping statement about container managed security which
    implied that things should just work. Someone has to make them work.

    As an app developer you might not have to worry about how the bits
    behind the API work, but some admin has to configure it properly.

    API is a contract between the container and the developer, the
    contract specifies how a developer would access role information
    regardless of the implementation. Since the Realm implementation
    assumes that Tomcat is doing the authentication and breaks when it
    isn't Tomcat, isn't that a violation of the contract?
    No. I don't think it is.

    Your specific need might not be handled by the Realm implementations
    supplied with Tomcat, but that's not proof that either design of Realms
    is flawed or that Tomcat isn't spec compliant.

    It's open
    source, so I'm not complaining or demanding anything. I think I know
    how to do what I need however that doesn't change the facts of the
    situation that Tomcat does not have the built in capability for a
    standard realm to simply retrieve user infomation as opposed to
    authentication AND user retrieval that would enable Tomcat to maintain
    its compliance while being fronted by Apache.
    The explanation you provided in your 3rd email doesn't sound like
    'simply' to me. You also state that other servlet containers need a 3rd
    party agent to achieve the desired result.

    If your complaint is accurate then the other 3 servers you name must
    also 'violate the contract' because they don't provide what you need out
    of the box.


    p
  • Marc Boorshtein at Jun 17, 2010 at 12:02 pm

    I'm not looking to start a holy war here, but is there anything
    incorrect in what I said?  Tomcat is a servlet container, the servlet
    Yes.

    You made a sweeping statement about container managed security which
    implied that things should just work.  Someone has to make them work.

    As an app developer you might not have to worry about how the bits
    behind the API work, but some admin has to configure it properly.
    No argument there. Thats what I started trying to figure out. As I
    said this is a Commercial Off The Shelf application that was built to
    the Servlet API specification. I didn't develop the app but given the
    app is written to the Servlet API there are certain expectations do to
    how the api is written.

    API is a contract between the container and the developer, the
    contract specifies how a developer would access role information
    regardless of the implementation.  Since the Realm implementation
    assumes that Tomcat is doing the authentication and breaks when it
    isn't Tomcat, isn't that a violation of the contract?
    No.  I don't think it is.

    Your specific need might not be handled by the Realm implementations
    supplied with Tomcat, but that's not proof that either design of Realms
    is flawed or that Tomcat isn't spec compliant.
    The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the
    authentication unless you do a 100% custom realm. This is ultimately
    how I solved my issue (I make a copy of JNDIRealm and took out the
    credential check). Why I feel this is an issue with Tomcat's
    implementation is explained below.
    It's open
    source, so I'm not complaining or demanding anything.  I think I know
    how to do what I need however that doesn't change the facts of the
    situation that Tomcat does not have the built in capability for a
    standard realm to simply retrieve user infomation as opposed to
    authentication AND user retrieval that would enable Tomcat to maintain
    its compliance while being fronted by Apache.
    The explanation you provided in your 3rd email doesn't sound like
    'simply' to me.  You also state that other servlet containers need a 3rd
    party agent to achieve the desired result.

    If your complaint is accurate then the other 3 servers you name must
    also 'violate the contract' because they don't provide what you need out
    of the box.
    The way WebSphere and Weblogic work (I've not done this integration
    with JBoss so I can't speak to it) there is a security subsystem that
    seperates user & group retrieval from actual authentication. The
    reason for this is to allow third party authentication providers to be
    plugged into the system without changing how the application server
    retrieves user information.

    Here's the flow of how WebSphere with SiteMinder integrates:

    1. User accesses URL pointing to IHS (an apache variant)
    2. SiteMinder "agent" in IHS authenticates and authorizes the user
    3. WebSphere plugin (which would be a peer to mod_jk) forwards the
    request to WebSphere
    4. WebSphere executes a "TAI" (I forget what the acronym stands for)
    that is provided by the vendor (in this case CA) validate the request
    and provide WebSphere with the user's principal. Websphere also
    exposes its API to the TAI for retrieving user information for
    building the Principal object.
    5. WebSphere executes it's security configuration as it executes the request

    It is a similar process for Oracle Access Manager and IBM Tivoli
    Access Manager as well with Oracle Weblogic. The critical point here
    is that if you swapped out any of the above Web Access Managers (or
    even replace them with Federation systems like Ping) you don't change
    how WebSphere RETRIEVES user information and do not need to recode the
    application. The only portion that gets changed is the third party
    integration tool. This was the intent of including security
    components in the Servlet API.

    So do I think Tomcat needs to support every WAM or Federation system?
    No, that would be completely unreasonable. Do I think that Tomcat
    should not require a re-coding of a component that has nothing to do
    with authentication when changing authentication systems? Yes. I do
    think that is reasonable. I think its reasonable that if I provide
    the authentication mechanism that Tomcat should be able to accept it
    and retrieve the user information without being forced to do the
    authentication on its own.

    I want to be clear. I think Tomcat is a great product and like all
    great products it has it's strengths and weaknesses. Even between the
    1/2 hour of coding I had to do to get the solution working, the bit
    more coding I'll have to do once I move from Basic authentication to
    form based and the very interesting conversation on this list it still
    took me less time to do it in tomcat then to get Weblogic setup,
    installed and configured!

    Thanks
    Marc

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Pid at Jun 17, 2010 at 12:10 pm

    On 17/06/2010 12:34, Marc Boorshtein wrote:

    I'm not looking to start a holy war here, but is there anything
    incorrect in what I said? Tomcat is a servlet container, the servlet
    Yes.

    You made a sweeping statement about container managed security which
    implied that things should just work. Someone has to make them work.

    As an app developer you might not have to worry about how the bits
    behind the API work, but some admin has to configure it properly.
    No argument there. Thats what I started trying to figure out. As I
    said this is a Commercial Off The Shelf application that was built to
    the Servlet API specification. I didn't develop the app but given the
    app is written to the Servlet API there are certain expectations do to
    how the api is written.

    API is a contract between the container and the developer, the
    contract specifies how a developer would access role information
    regardless of the implementation. Since the Realm implementation
    assumes that Tomcat is doing the authentication and breaks when it
    isn't Tomcat, isn't that a violation of the contract?
    No. I don't think it is.

    Your specific need might not be handled by the Realm implementations
    supplied with Tomcat, but that's not proof that either design of Realms
    is flawed or that Tomcat isn't spec compliant.
    The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the
    authentication unless you do a 100% custom realm. This is ultimately
    how I solved my issue (I make a copy of JNDIRealm and took out the
    credential check). Why I feel this is an issue with Tomcat's
    implementation is explained below.
    It's open
    source, so I'm not complaining or demanding anything. I think I know
    how to do what I need however that doesn't change the facts of the
    situation that Tomcat does not have the built in capability for a
    standard realm to simply retrieve user infomation as opposed to
    authentication AND user retrieval that would enable Tomcat to maintain
    its compliance while being fronted by Apache.
    The explanation you provided in your 3rd email doesn't sound like
    'simply' to me. You also state that other servlet containers need a 3rd
    party agent to achieve the desired result.

    If your complaint is accurate then the other 3 servers you name must
    also 'violate the contract' because they don't provide what you need out
    of the box.
    The way WebSphere and Weblogic work (I've not done this integration
    with JBoss so I can't speak to it) there is a security subsystem that
    seperates user & group retrieval from actual authentication. The
    reason for this is to allow third party authentication providers to be
    plugged into the system without changing how the application server
    retrieves user information.
    So is the problem that Tomcat doesn't provide the same pluggability that
    the other (full JEE servers) do?
    Here's the flow of how WebSphere with SiteMinder integrates:

    1. User accesses URL pointing to IHS (an apache variant)
    2. SiteMinder "agent" in IHS authenticates and authorizes the user
    3. WebSphere plugin (which would be a peer to mod_jk) forwards the
    request to WebSphere
    4. WebSphere executes a "TAI" (I forget what the acronym stands for)
    that is provided by the vendor (in this case CA) validate the request
    and provide WebSphere with the user's principal. Websphere also
    exposes its API to the TAI for retrieving user information for
    building the Principal object.
    5. WebSphere executes it's security configuration as it executes the request

    It is a similar process for Oracle Access Manager and IBM Tivoli
    Access Manager as well with Oracle Weblogic. The critical point here
    is that if you swapped out any of the above Web Access Managers (or
    even replace them with Federation systems like Ping) you don't change
    how WebSphere RETRIEVES user information and do not need to recode the
    application. The only portion that gets changed is the third party
    integration tool. This was the intent of including security
    components in the Servlet API.
    Because the pluggable 3rd party agent handles that for you?

    So do I think Tomcat needs to support every WAM or Federation system?
    No, that would be completely unreasonable. Do I think that Tomcat
    should not require a re-coding of a component that has nothing to do
    with authentication when changing authentication systems? Yes. I do
    think that is reasonable. I think its reasonable that if I provide
    the authentication mechanism that Tomcat should be able to accept it
    and retrieve the user information without being forced to do the
    authentication on its own.
    Surely that's subjective, it depends entirely on the authentication &
    authorization mechanism you want to use. I wouldn't expect Tomcat to be
    able to effect authorization when I've authenticated by Internet
    Telepathy(tm). (To pick a wildly unreasonable alternative)

    I want to be clear. I think Tomcat is a great product and like all
    great products it has it's strengths and weaknesses. Even between the
    1/2 hour of coding I had to do to get the solution working, the bit
    more coding I'll have to do once I move from Basic authentication to
    form based and the very interesting conversation on this list it still
    took me less time to do it in tomcat then to get Weblogic setup,
    installed and configured!
    You can always contribute it back.


    p
    Thanks
    Marc

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • André Warnier at Jun 17, 2010 at 12:27 pm

    Pid wrote:
    On 17/06/2010 12:34, Marc Boorshtein wrote:
    I'm not looking to start a holy war here, but is there anything
    incorrect in what I said? Tomcat is a servlet container, the servlet
    Yes.

    You made a sweeping statement about container managed security which
    implied that things should just work. Someone has to make them work.

    As an app developer you might not have to worry about how the bits
    behind the API work, but some admin has to configure it properly.
    No argument there. Thats what I started trying to figure out. As I
    said this is a Commercial Off The Shelf application that was built to
    the Servlet API specification. I didn't develop the app but given the
    app is written to the Servlet API there are certain expectations do to
    how the api is written.

    API is a contract between the container and the developer, the
    contract specifies how a developer would access role information
    regardless of the implementation. Since the Realm implementation
    assumes that Tomcat is doing the authentication and breaks when it
    isn't Tomcat, isn't that a violation of the contract?
    No. I don't think it is.

    Your specific need might not be handled by the Realm implementations
    supplied with Tomcat, but that's not proof that either design of Realms
    is flawed or that Tomcat isn't spec compliant.
    The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the
    authentication unless you do a 100% custom realm. This is ultimately
    how I solved my issue (I make a copy of JNDIRealm and took out the
    credential check). Why I feel this is an issue with Tomcat's
    implementation is explained below.
    It's open
    source, so I'm not complaining or demanding anything. I think I know
    how to do what I need however that doesn't change the facts of the
    situation that Tomcat does not have the built in capability for a
    standard realm to simply retrieve user infomation as opposed to
    authentication AND user retrieval that would enable Tomcat to maintain
    its compliance while being fronted by Apache.
    The explanation you provided in your 3rd email doesn't sound like
    'simply' to me. You also state that other servlet containers need a 3rd
    party agent to achieve the desired result.

    If your complaint is accurate then the other 3 servers you name must
    also 'violate the contract' because they don't provide what you need out
    of the box.
    The way WebSphere and Weblogic work (I've not done this integration
    with JBoss so I can't speak to it) there is a security subsystem that
    seperates user & group retrieval from actual authentication. The
    reason for this is to allow third party authentication providers to be
    plugged into the system without changing how the application server
    retrieves user information.
    So is the problem that Tomcat doesn't provide the same pluggability that
    the other (full JEE servers) do?
    Here's the flow of how WebSphere with SiteMinder integrates:

    1. User accesses URL pointing to IHS (an apache variant)
    2. SiteMinder "agent" in IHS authenticates and authorizes the user
    3. WebSphere plugin (which would be a peer to mod_jk) forwards the
    request to WebSphere
    4. WebSphere executes a "TAI" (I forget what the acronym stands for)
    that is provided by the vendor (in this case CA) validate the request
    and provide WebSphere with the user's principal. Websphere also
    exposes its API to the TAI for retrieving user information for
    building the Principal object.
    5. WebSphere executes it's security configuration as it executes the request

    It is a similar process for Oracle Access Manager and IBM Tivoli
    Access Manager as well with Oracle Weblogic. The critical point here
    is that if you swapped out any of the above Web Access Managers (or
    even replace them with Federation systems like Ping) you don't change
    how WebSphere RETRIEVES user information and do not need to recode the
    application. The only portion that gets changed is the third party
    integration tool. This was the intent of including security
    components in the Servlet API.
    Because the pluggable 3rd party agent handles that for you?

    So do I think Tomcat needs to support every WAM or Federation system?
    No, that would be completely unreasonable. Do I think that Tomcat
    should not require a re-coding of a component that has nothing to do
    with authentication when changing authentication systems? Yes. I do
    think that is reasonable. I think its reasonable that if I provide
    the authentication mechanism that Tomcat should be able to accept it
    and retrieve the user information without being forced to do the
    authentication on its own.
    Surely that's subjective, it depends entirely on the authentication &
    authorization mechanism you want to use. I wouldn't expect Tomcat to be
    able to effect authorization when I've authenticated by Internet
    Telepathy(tm). (To pick a wildly unreasonable alternative)

    I want to be clear. I think Tomcat is a great product and like all
    great products it has it's strengths and weaknesses. Even between the
    1/2 hour of coding I had to do to get the solution working, the bit
    more coding I'll have to do once I move from Basic authentication to
    form based and the very interesting conversation on this list it still
    took me less time to do it in tomcat then to get Weblogic setup,
    installed and configured!
    You can always contribute it back.
    Hi.
    I must say that, with my limited knowledge of the Tomcat internals taken into
    consideration, I tend to agree with Marc in this case, if he is right in claiming that the
    Tomcat Realm mixes authentication with authorization and does not allow to separate the two.
    At the very least, I would expect the Realm to check first if the request already has a
    user-id, and skip the authentication part in such a case.
    There are many cases out there were Tomcat is only a part of a more complex system, where
    a network-wide authentication is required, while the authorization part may still be one
    that only Tomcat can do.

    A naive linked question : is the <Realm> a purely Tomcat thing, or is it mandated by the
    Servlet Spec ?


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Mark Thomas at Jun 17, 2010 at 1:24 pm

    On 17/06/2010 13:26, André Warnier wrote:
    I must say that, with my limited knowledge of the Tomcat internals taken
    into consideration, I tend to agree with Marc in this case, if he is
    right in claiming that the Tomcat Realm mixes authentication with
    authorization and does not allow to separate the two.
    That is how Tomcat Realms are designed. This is consistent with the
    Servlet sepc that leaves the implementation details entirely to the
    container. If Tomcat required all authentication requests to be made via
    carrier pigeon then that would be spec complaint providing the correct
    information was exposed via the API defined in the spec.
    At the very least, I would expect the Realm to check first if the
    request already has a user-id, and skip the authentication part in such
    a case.
    Easier said than done. The Realms deliberately have no visibility of the
    request or the response. The Authenticators extract the username and
    password, pass them to the realm to obtain an authenticated Principal
    (with roles) and then the Authenitcators populate the attributes that
    then support the calls in the Servlet API.

    The way to handle this (probably) is to modify the Authenticators
    (hopefully just the base class) to check for an already authenticated
    user. If one is found, use the realms just to get the roles. The
    implementation for that is already in place. It just needs adding to the
    interface and the visibility changed. Then you just need to figure out
    how to merge the existing Principal (that may have roles) with the new
    one that has the roles from the Realm.

    Tomcat 7's internal API has deliberately been declared as volatile inthe
    docs so now is the time to make these changes. Patches welcome.

    Note this won't get ported back to 6 due to the API changes required.
    There are many cases out there were Tomcat is only a part of a more
    complex system, where a network-wide authentication is required, while
    the authorization part may still be one that only Tomcat can do.

    A naive linked question : is the <Realm> a purely Tomcat thing, or is it
    mandated by the Servlet Spec ?
    100% pure Tomcat.

    Mark



    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Marc Boorshtein at Jun 17, 2010 at 1:58 pm

    On Thu, Jun 17, 2010 at 9:11 AM, Mark Thomas wrote:
    On 17/06/2010 13:26, André Warnier wrote:
    I must say that, with my limited knowledge of the Tomcat internals taken
    into consideration, I tend to agree with Marc in this case, if he is
    right in claiming that the Tomcat Realm mixes authentication with
    authorization and does not allow to separate the two.
    That is how Tomcat Realms are designed. This is consistent with the
    Servlet sepc that leaves the implementation details entirely to the
    container. If Tomcat required all authentication requests to be made via
    carrier pigeon then that would be spec complaint providing the correct
    information was exposed via the API defined in the spec.

    Yes, it is as long as Tomcat is not combined with Apache or IIS. Once
    Tomcat offloads the authentication to Apache/IIS there should be a
    mechanism in place to still continue the authorization framework.
    At the very least, I would expect the Realm to check first if the
    request already has a user-id, and skip the authentication part in such
    a case.
    Easier said than done. The Realms deliberately have no visibility of the
    request or the response. The Authenticators extract the username and
    password, pass them to the realm to obtain an authenticated Principal
    (with roles) and then the Authenitcators populate the attributes that
    then support the calls in the Servlet API.

    The way to handle this (probably) is to modify the Authenticators
    (hopefully just the base class) to check for an already authenticated
    user. If one is found, use the realms just to get the roles. The
    implementation for that is already in place. It just needs adding to the
    interface and the visibility changed. Then you just need to figure out
    how to merge the existing Principal (that may have roles) with the new
    one that has the roles from the Realm.

    Tomcat 7's internal API has deliberately been declared as volatile inthe
    docs so now is the time to make these changes. Patches welcome.

    Note this won't get ported back to 6 due to the API changes required.

    I'll take a look at the tomcat 7 api and see what I can do.

    Marc

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Pid at Jun 17, 2010 at 1:51 pm

    On 17/06/2010 13:26, André Warnier wrote:
    Pid wrote:
    On 17/06/2010 12:34, Marc Boorshtein wrote:
    I'm not looking to start a holy war here, but is there anything
    incorrect in what I said? Tomcat is a servlet container, the servlet
    Yes.

    You made a sweeping statement about container managed security which
    implied that things should just work. Someone has to make them work.

    As an app developer you might not have to worry about how the bits
    behind the API work, but some admin has to configure it properly.
    No argument there. Thats what I started trying to figure out. As I
    said this is a Commercial Off The Shelf application that was built to
    the Servlet API specification. I didn't develop the app but given the
    app is written to the Servlet API there are certain expectations do to
    how the api is written.

    API is a contract between the container and the developer, the
    contract specifies how a developer would access role information
    regardless of the implementation. Since the Realm implementation
    assumes that Tomcat is doing the authentication and breaks when it
    isn't Tomcat, isn't that a violation of the contract?
    No. I don't think it is.

    Your specific need might not be handled by the Realm implementations
    supplied with Tomcat, but that's not proof that either design of Realms
    is flawed or that Tomcat isn't spec compliant.
    The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the
    authentication unless you do a 100% custom realm. This is ultimately
    how I solved my issue (I make a copy of JNDIRealm and took out the
    credential check). Why I feel this is an issue with Tomcat's
    implementation is explained below.
    It's open
    source, so I'm not complaining or demanding anything. I think I know
    how to do what I need however that doesn't change the facts of the
    situation that Tomcat does not have the built in capability for a
    standard realm to simply retrieve user infomation as opposed to
    authentication AND user retrieval that would enable Tomcat to maintain
    its compliance while being fronted by Apache.
    The explanation you provided in your 3rd email doesn't sound like
    'simply' to me. You also state that other servlet containers need a
    3rd
    party agent to achieve the desired result.

    If your complaint is accurate then the other 3 servers you name must
    also 'violate the contract' because they don't provide what you need
    out
    of the box.
    The way WebSphere and Weblogic work (I've not done this integration
    with JBoss so I can't speak to it) there is a security subsystem that
    seperates user & group retrieval from actual authentication. The
    reason for this is to allow third party authentication providers to be
    plugged into the system without changing how the application server
    retrieves user information.
    So is the problem that Tomcat doesn't provide the same pluggability that
    the other (full JEE servers) do?
    Here's the flow of how WebSphere with SiteMinder integrates:

    1. User accesses URL pointing to IHS (an apache variant)
    2. SiteMinder "agent" in IHS authenticates and authorizes the user
    3. WebSphere plugin (which would be a peer to mod_jk) forwards the
    request to WebSphere
    4. WebSphere executes a "TAI" (I forget what the acronym stands for)
    that is provided by the vendor (in this case CA) validate the request
    and provide WebSphere with the user's principal. Websphere also
    exposes its API to the TAI for retrieving user information for
    building the Principal object.
    5. WebSphere executes it's security configuration as it executes the
    request

    It is a similar process for Oracle Access Manager and IBM Tivoli
    Access Manager as well with Oracle Weblogic. The critical point here
    is that if you swapped out any of the above Web Access Managers (or
    even replace them with Federation systems like Ping) you don't change
    how WebSphere RETRIEVES user information and do not need to recode the
    application. The only portion that gets changed is the third party
    integration tool. This was the intent of including security
    components in the Servlet API.
    Because the pluggable 3rd party agent handles that for you?

    So do I think Tomcat needs to support every WAM or Federation system?
    No, that would be completely unreasonable. Do I think that Tomcat
    should not require a re-coding of a component that has nothing to do
    with authentication when changing authentication systems? Yes. I do
    think that is reasonable. I think its reasonable that if I provide
    the authentication mechanism that Tomcat should be able to accept it
    and retrieve the user information without being forced to do the
    authentication on its own.
    Surely that's subjective, it depends entirely on the authentication &
    authorization mechanism you want to use. I wouldn't expect Tomcat to be
    able to effect authorization when I've authenticated by Internet
    Telepathy(tm). (To pick a wildly unreasonable alternative)

    I want to be clear. I think Tomcat is a great product and like all
    great products it has it's strengths and weaknesses. Even between the
    1/2 hour of coding I had to do to get the solution working, the bit
    more coding I'll have to do once I move from Basic authentication to
    form based and the very interesting conversation on this list it still
    took me less time to do it in tomcat then to get Weblogic setup,
    installed and configured!
    You can always contribute it back.
    Hi.
    I must say that, with my limited knowledge of the Tomcat internals taken
    into consideration, I tend to agree with Marc in this case, if he is
    right in claiming that the Tomcat Realm mixes authentication with
    authorization and does not allow to separate the two.
    Well, he said he's managed to make it work, so it must be possible to
    separate the two.

    As far as I could tell, his major complaint was that it didn't just work
    'out of the box' (but it needs a 3rd party agent in the other examples).
    He also threw in a complaint about contract violations which I didn't
    think was fair, or valid.
    At the very least, I would expect the Realm to check first if the
    request already has a user-id, and skip the authentication part in such
    a case.
    The Realm doesn't see the request at all.
    There are many cases out there were Tomcat is only a part of a more
    complex system, where a network-wide authentication is required, while
    the authorization part may still be one that only Tomcat can do.
    I don't think the Servlet Spec defines a situation where authentication
    and authorisation occur separately, but I'm happy to be corrected.

    The Spec defines some methods of authentication & authorization (BASIC,
    FORM, etc), and some objects associated with the request which describe
    some properties of an authenticated user principal, and it's roles.

    It also makes statements about what Containers must provide API wise,
    but it doesn't say how.

    A naive linked question : is the <Realm> a purely Tomcat thing, or is it
    mandated by the Servlet Spec ?
    It's a Tomcat thing, as are the Authenticators and Valves.


    p
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Marc Boorshtein at Jun 17, 2010 at 2:09 pm

    Hi.
    I must say that, with my limited knowledge of the Tomcat internals taken
    into consideration, I tend to agree with Marc in this case, if he is
    right in claiming that the Tomcat Realm mixes authentication with
    authorization and does not allow to separate the two.
    Well, he said he's managed to make it work, so it must be possible to
    separate the two.
    I got it to work by writing custom code (namely I commented out the
    "bind" in the JNDIRealm). Thats OK for my own needs building a POC
    but I wouldn't use it in production.
    As far as I could tell, his major complaint was that it didn't just work
    'out of the box' (but it needs a 3rd party agent in the other examples).
    He also threw in a complaint about contract violations which I didn't
    think was fair, or valid.
    So apparently you didn't actually READ what I wrote in my previous
    email. I would suggest you do as it is quite detailed and pinpoints
    exactly what my "complaint" is.
    At the very least, I would expect the Realm to check first if the
    request already has a user-id, and skip the authentication part in such
    a case.
    The Realm doesn't see the request at all.
    This is what the "base" problem probably is. The authentication
    mechanism doesn't have the conext to make decisions
    There are many cases out there were Tomcat is only a part of a more
    complex system, where a network-wide authentication is required, while
    the authorization part may still be one that only Tomcat can do.
    I don't think the Servlet Spec defines a situation where authentication
    and authorisation occur separately, but I'm happy to be corrected.
    No, it doesn't. It just defines an API that should work regardless.
    The Spec defines some methods of authentication & authorization (BASIC,
    FORM, etc), and some objects associated with the request which describe
    some properties of an authenticated user principal, and it's roles.

    It also makes statements about what Containers must provide API wise,
    but it doesn't say how.
    Yes. Thats my point. It should be transparent. I (or any developer)
    that writes my app to the spec should not have to recode their
    applicatoin because the container doesn't handle a common
    configuration change such as externalizing authentication.

    I'd be happy to share how I was able to get this to work...where is
    the best place, the wiki?

    Marc

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Pid at Jun 17, 2010 at 3:05 pm

    On 17/06/2010 15:08, Marc Boorshtein wrote:
    Hi.
    I must say that, with my limited knowledge of the Tomcat internals taken
    into consideration, I tend to agree with Marc in this case, if he is
    right in claiming that the Tomcat Realm mixes authentication with
    authorization and does not allow to separate the two.
    Well, he said he's managed to make it work, so it must be possible to
    separate the two.
    I got it to work by writing custom code (namely I commented out the
    "bind" in the JNDIRealm). Thats OK for my own needs building a POC
    but I wouldn't use it in production.
    As far as I could tell, his major complaint was that it didn't just work
    'out of the box' (but it needs a 3rd party agent in the other examples).
    He also threw in a complaint about contract violations which I didn't
    think was fair, or valid.
    So apparently you didn't actually READ what I wrote in my previous
    email. I would suggest you do as it is quite detailed and pinpoints
    exactly what my "complaint" is.
    Steady now. You might not like my take on it, but I read it.

    At the very least, I would expect the Realm to check first if the
    request already has a user-id, and skip the authentication part in such
    a case.
    The Realm doesn't see the request at all.
    This is what the "base" problem probably is. The authentication
    mechanism doesn't have the conext to make decisions
    There are many cases out there were Tomcat is only a part of a more
    complex system, where a network-wide authentication is required, while
    the authorization part may still be one that only Tomcat can do.
    I don't think the Servlet Spec defines a situation where authentication
    and authorisation occur separately, but I'm happy to be corrected.
    No, it doesn't. It just defines an API that should work regardless.
    That's a fairly sweeping statement you've made there.

    The Spec defines some methods of authentication & authorization (BASIC,
    FORM, etc), and some objects associated with the request which describe
    some properties of an authenticated user principal, and it's roles.

    It also makes statements about what Containers must provide API wise,
    but it doesn't say how.
    Yes. Thats my point. It should be transparent.
    It is. You've still got to plug something into the back of the API to
    make it do what you want. If what you want is something complicated
    then maybe Tomcat won't do that without modification, as you've found.

    I (or any developer)
    that writes my app to the spec should not have to recode their
    applicatoin because the container doesn't handle a common
    configuration change such as externalizing authentication.
    You're talking about having to change your app, but you've only
    described having to make modifications to a Tomcat internal support class.

    You seem to be saying that Tomcat has a compliancy issue - IMO the
    problem with leaving that unchallenged is that it breeds
    misunderstanding that would land back here sometime later.

    I don't think it's reasonable to mix an argument about spec compliancy
    with an point about something that isn't covered by the spec - even if
    it is a common requirement.

    I'd be happy to share how I was able to get this to work...where is
    the best place, the wiki?
    Yep.


    p

    (Enough now.)


    Marc

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Marc Boorshtein at Jun 17, 2010 at 3:24 pm

    You're talking about having to change your app, but you've only
    described having to make modifications to a Tomcat internal support class.

    You seem to be saying that Tomcat has a compliancy issue - IMO the
    problem with leaving that unchallenged is that it breeds
    misunderstanding that would land back here sometime later.

    I don't think it's reasonable to mix an argument about spec compliancy
    with an point about something that isn't covered by the spec - even if
    it is a common requirement.
    We can agree to disagree on this one. Either way Tomcat 6 can not
    support a very common pattern in application deployment. I think it
    would be valuable for Tomcat to support this model and will work on
    I'll take a look at the 7 code to see how I can help.

    Marc

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

Related Discussions

Discussion Navigation
viewthread | post