Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

JGuard 1.0.3 WebApp: guest && Accessfilter

chk
2009-02-06
2013-05-08
  • chk
    chk
    2009-02-06

    Hello,
    is there a way not to configure a guest account in a struts app? I have don so because
    If I don't I will not get routed to the login-page in case I request an access-controlled page.
    Any hints what I have done wrong?

    regards, chk

     
    • chk
      chk
      2009-02-06

      Sorry,
      I just have seen that I have posted into the wrong newsgroup.
      Greets chk

       
    • Charles Lescot
      Charles Lescot
      2009-02-06

      Hi,
      I've not understood why you don't need a guest user.
      can you reexplain to me please?

      thanks,

      Charles.

       
      • chk
        chk
        2009-02-08

        Hi Charles,
        I develop an application for a closed user group. Therefore the customer does not want a guest user which would act like a public access to certain pages.
        I would expect following behaviour in respect to authentication.
        Assume, a user has an account but is not yet authenticated
        1.) the user requests a secured page
        2.) Since the user is not yet logged in the application displays the login page
        3.) the user enters the correct credentials and the application redirects the user to the requested page.
        Question: can I realize this mechanism with JGuard? If so, which configuration is necessary for this? (I believe JGuard is able because else you do not need the tag <goToLastAccessDeniedUriOnSuccess>true</goToLastAccessDeniedUriOnSuccess> in the JGuardFilter.mxl

        What is the role of the guest in this scenario?
        The following lines are taken from your documentation:
        "1. The user tries to access a protected URL. If the AccessFilter intercepts the request and verifies that the URL is a special URL, that it is not controlled (logonURI, authenticationFailedURI, accessjGuard
        on JEE applications DeniedURI), then go to the step 2, else go to step 3
        2. The request continues and user goes to the desired URL
        3. AccessFilter verifies if the user is authenticated. If the user is not authenticated then go to the step 4,
        otherwise go to step 5
        4. The filter verifies if there the request contains the login and password data. If not, the jGuard uses GUEST/GUEST to authenticate as a guest. Now go to step 5
        5. The filter tries to authenticate the user by the application's loginModule(s). If authentication is successful go to step 6, else go to step 7
        6. The authenticated Subject is stored in the session and the user redirected to indexURI page
        7. The user is redirected to authenticationFailedURI because the authentication failed
        "
        Those lines applied to the scenario implies that if the person is not authenticated it is identified as guest and the login page is not display because the user is logged in a "guest"
        Am I right?

        My application behaves like follows:
        In case I do not enter the following lines into JGuardUsersPrincipals.xml
        "
        <user>
                <privateCredentials>
                <credential>
                    <id>password</id>
                    <value>guest</value>
                </credential>   
                <credential>
                    <id>login</id>
                    <value>guest</value>
                </credential>
                </privateCredentials>
               
                <publicCredentials>
                <credential>
                    <id>ID</id>
                    <value>0</value>
                </credential>
                </publicCredentials>
               
                <principalsRef>
                <principalRef name="guestprincipal" applicationName="myApp" />
                </principalsRef>
            </user>
        "
        the app runs into a infinite loop of authentication.
        Why is it like that?
        In case I enter the above code and use enter my real user's credentials into the login page, I am only authenticated as guest and not as my real user. I end in the authorizationFailed trail configured in the JGuardFilter.xml. Only after the 2nd attempt of login I will be authenticated as real user.
        Is it that I have misconfigured sth.?
        Here are the related file:

        <configuration>
            <filter>
            <indexURI>/IGLAccess.igl</indexURI>
            <authenticationFailedURI>/AuthenticationFailed.igl</authenticationFailedURI>
                       
            <!--URI fuer die Seite, welche das Login-Form enthält, in diesem Fall
                            ist es eine logische Referenz, die in der struts-config.xml aufgeloest wird.
                            Siehe jGuard-Doku 2.3.1.1.1
                        -->
            <logonURI>/Go4Authentication.igl</logonURI>
           
            <!--Fuer die IGLSeiten: URI, an welche die Credentials des users geschickt
                            werden, zwecks Authentisierung. Das ist eine logische URI, welche in der
                            struts-config.xml aufgelöst wird.
                            Siehe jGuard-Doku 2.3.1.1.1
                        -->
            <logonProcessURI>/Authenticated.igl</logonProcessURI>
           
           
        <registerURI>/Registration.igl</registerURI>
            <registerProcessURI></registerProcessURI>
           
            <logoffURIs>
                <logoffURI>/LogOff.igl</logoffURI>
            </logoffURIs>             
           
            <!-- uri when access to a ressource is denied -->
            <accessDeniedURI>/AccessDenied.igl</accessDeniedURI>
            <authScheme>FORM</authScheme>
            <loginField>username</loginField>
            <passwordField>password</passwordField>
            <goToLastAccessDeniedUriOnSuccess>true</goToLastAccessDeniedUriOnSuccess>
            </filter>
        </configuration>

        JGuardUserPrincipals.xml
        "
        <usersPrincipals>
            <principals>
           
            <principal>
                <name>membermanagementprincipal</name>
                <class>net.sf.jguard.core.principals.RolePrincipal</class>
                <applicationName>iglSeiten</applicationName>
            </principal>
           
            <principal>       
                <name>fishmanagementprincipal</name>
                <class>net.sf.jguard.core.principals.RolePrincipal</class>
                <applicationName>iglSeiten</applicationName>
            </principal>
            <principal>
                <name>adminprincipal</name>
                <class>net.sf.jguard.core.principals.RolePrincipal</class>
                <applicationName>iglSeiten</applicationName>
            </principal>
            <principal>
                <name>kaderprincipal</name>
                <class>net.sf.jguard.core.principals.RolePrincipal</class>
                <applicationName>iglSeiten</applicationName>
            </principal>
           
            <principal>
                <name>memberprincipal</name>
                <class>net.sf.jguard.core.principals.RolePrincipal</class>
                <applicationName>iglSeiten</applicationName>
            </principal>
            <principal>
                <name>guestprincipal</name>
                <class>net.sf.jguard.core.principals.RolePrincipal</class>
                <applicationName>iglSeiten</applicationName>
            </principal>
            </principals>
           
            <users>
            <userTemplate>
                <name>default</name>
                <privateRequiredCredentials>             
                <credTemplateId>password</credTemplateId>
                <credTemplateId identity="true">login</credTemplateId>
                </privateRequiredCredentials>
               
                <publicRequiredCredentials>   
                <credTemplateId>iglnr</credTemplateId>
                </publicRequiredCredentials>
               
                <privateOptionalCredentials>
                </privateOptionalCredentials>
               
                <publicOptionalCredentials>
                </publicOptionalCredentials>
               
                <!--Zuordnung des Principals nach Login eines neuen Users-->
                <genericPrincipals>
                <principalRef name="memberprincipal" applicationName="iglSeiten"/>
                </genericPrincipals>
                <specificPrincipalFactories/>
            </userTemplate>
           

            <user><!--JGuard implicit Account-->
                <privateCredentials>
                <credential>
                    <id>password</id>
                    <value>guest</value>
                </credential>   
                <credential>
                    <id>login</id>
                    <value>guest</value>
                </credential>
                </privateCredentials>
               
                <publicCredentials>
                <credential>
                    <id>iglnr</id>
                    <value>0</value>
                </credential>
                </publicCredentials>
               
                <principalsRef>
                <principalRef name="guestprincipal" applicationName="iglSeiten" />
                </principalsRef>
            </user>
               
            <!-- die Rolle des Admins -->
            <user>
                <privateCredentials>
                <credential>
                    <id>password</id>
                    <value>dinekli</value>
                </credential>
               
                <credential>
                    <id>login</id>
                    <value>chk</value>
                </credential>
                </privateCredentials>
               
                <publicCredentials>
                <credential>
                    <id>iglnr</id>
                    <value>103</value>
                </credential>
                </publicCredentials>
               
                <principalsRef>
                <principalRef name="adminprincipal" applicationName="iglSeiten" />
                </principalsRef>
            </user>
           
           
            <user>
                <privateCredentials>
                <credential>
                    <id>password</id>
                    <value>member</value>
                </credential> 
                <credential>
                    <id>login</id>
                    <value>member</value>
                </credential>
               
                </privateCredentials>
               
                <publicCredentials>
                <credential>
                    <id>iglnr</id>
                    <value>1</value>
                </credential>
                </publicCredentials>
               
                <principalsRef>
                <principalRef name="memberprincipal" applicationName="iglSeiten" />
                </principalsRef>
            </user>   
            </users>
        </usersPrincipals>
        "

        Can you see what is wrong with this configuration?

        Regards, chk

         
        • Charles Lescot
          Charles Lescot
          2009-02-08

          Hi,
          "Question: can I realize this mechanism with JGuard"
          => yes
          "If so, which configuration
          is necessary for this? "
          <goToLastAccessDeniedUriOnSuccess>true</goToLastAccessDeniedUriOnSuccess> in jGuardFilter.xml is the solution

          "Those lines applied to the scenario implies that if the person is not authenticated
          it is identified as guest and the login page is not display because the user
          is logged in a "guest"
          Am I right?"
          => yes, you're right.

          about the infinite loop:
          you must always declare a guest user, because any request in jguard is enforced against user rights.
          if you're not  authenticated actively, jguard auto-authenticate you  as a guest and enforce the resource requested against guest permissions. so, with this configuration, jguard can knows which roles the guest user has got.

          about your configuration, it seems right.....
          for a better understanding of what's wrong, can you set to debug the logging level og net.sf.jguard level, and can you publish the log during the two authentication processes ?
          also,have you tried the jguard-struts-example provided with the distribution?

          hope it helps,

          Charles.

           
          • chk
            chk
            2009-02-13

            Hi Charles,
            I really wonder after all, how can one realize the following behavior as described by you:
            "Hi,
            "Question: can I realize this mechanism with JGuard"
            => yes
            "If so, which configuration
            is necessary for this? "
            <Hi,
            "Question: can I realize this mechanism with JGuard"
            => yes
            "If so, which configuration
            is necessary for this? "
            <goToLastAccessDeniedUriOnSuccess>true</goToLastAccessDeniedUriOnSuccess> in jGuardFilter.xml is the solution >true</goToLastAccessDeniedUriOnSuccess> in jGuardFilter.xml is the solution "

            I really doubt (excuse me). If the filter has implemented the mechanism that in case of no given credentials, jguard attempts to login you as guest. Then, there is no need of  <goToLastAccessDeniedUriOnSuccess>.
            Right?
            Regards, chk

             
            • Charles Lescot
              Charles Lescot
              2009-02-15

              Hi,
              the log file provided implies that first authentication failed.
              can you tries to set the credential with key login ,and the credntial with key 'password'jguard-struts-example provided (which works like you want)?
              i think the issue is maybe caused by a different credential key (i.e not 'login' and 'password').

              hope it helps,
              Charles.

               
              • chk
                chk
                2009-02-17

                Hi Charles,
                I will do so. In fact I do have changed the names of the login and the password. But they are in synch with the configurations done in the JGuardFilter.xml (thats the right name of the filter configuration, isnt'it?).
                When I use the debugger, I can see that it checks the given credentials as well as the guest ones.
                Do you suspect an incorrect working of the filter configuration?
                Regards, chk

                 
                • Charles Lescot
                  Charles Lescot
                  2009-02-20

                  Hi,
                  despite some potential bugs in jGuard, i think the problem comes from the documentation because the jguard-struts-example 1.0.3 can do the mechanism wanted out of the box..

                  hope it helps,

                  Charles.

                   
                  • chk
                    chk
                    2009-02-21

                    Hi everybody,
                    well, the story of mine goes on like this.
                    I have made two things wrong.
                    1.) The first access to the webapp was not directed as struts command via the JGuard access filter (listening to the struts command pattern ending with ".igl"). Instead I accessed the webapp (a jsp-page with a command ending with ".jsp". The jsp page contained an struts command action in the html form-tag ending with .igl (the pattern the access filter listens to. When I had typed in valid credentials the one was not authenticated but only the guest account came into play (I suspect the access filter acting like that: is there a struts command the filter listens and if the user is not yet authenticated, create a guest principal for the request). The access filter neglects the given credentials
                    2.) I had not given any access right to the guest principal (I had realized only lately that JGuard uses a guest login by design. I found this hint in the FAQs of the JGuard documentation. From my point of view it should be treated explicitly and properly in the authentication chapter.) As a consequence I always had received an access denied error. I had always thought the access filter uses the given credentials for which access rights were associated. That was a wrong assumption of mine. After adding some rights to the guest principal, it started to work. 
                    What have I learned from that? The very first access of to a JGuard controlled webApp must be routed via the access filter and the page it accesses must be authorized for the guest.
                    What is it that I still have not learned? How can I make a redirect work with <goToLastAccessDeniedUriOnSuccess>true</goToLastAccessDeniedUriOnSuccess> set to true? The below log documents that it still does not work.
                    The usecase goes like that.
                    Starting an unauthenticated request to /IGLAccess.igl
                    WebApps struts-config.xml entry: <action path="/IGLAccess"
                            type="org.apache.struts.actions.ForwardAction"
                            parameter="/jsp/CentralPage.jsp" />

                    The struts command  /IGLAccess.igl is routed via the access filter (filter pattern: *.igl set in the web.xml) to a page to which the guest account is not authorized (guest account has public credential iglnr=0)
                    I expected that the access filter redirects me to the login page in which I can enter the user credentials. After an successful authentication I expected JGuard to redirect me back to the page  /jsp/CentralPage.jsp, my prior request.

                    19.02.2009 18:34:47 net.sf.jguard.ext.audit.AuditManager addEvent
                    INFO: user is null  :  subject is null  implies  logonProcess phase
                    19.02.2009 18:34:47 net.sf.jguard.ext.audit.AuditManager addEvent
                    INFO: user is null  :  AUTHENTICATION TYPE =FORM implies   authenticate phase 
                    19.02.2009 18:34:47 net.sf.jguard.ext.audit.AuditManager addEvent
                    INFO:  user= [  iglnr=0 ] :  user is authenticated  implies  redirect to /IGLAccess.igl
                    19.02.2009 18:34:47 net.sf.jguard.ext.audit.AuditManager addEvent
                    INFO:  user= [  iglnr=0 ] :  subject hasn't got the permission name=permissionFromUser actions=/IGLAccess.igl,ANY,GETpermission build from the user request implies  accessdenied phase
                    19.02.2009 18:34:47 net.sf.jguard.ext.audit.AuditManager addEvent
                    INFO:  user= [  iglnr=0 ] :  access is denied to/jserv/IGLAccess.igl implies  user is redirected to accessDeniedURI/AccessDenied.igl
                    19.02.2009 18:34:47 net.sf.jguard.ext.audit.AuditManager addEvent
                    INFO:  user= [  iglnr=0 ] : subject is not null and URI/AccessDenied.igl= accessDeniedURI( /AccessDenied.igl) implies  access authorized 

                    ... so far.
                    Regards, chk

                     
                    • Charles Lescot
                      Charles Lescot
                      2009-02-21

                      Hi,
                      thanks for the feedback.
                      i've included in the next release of the reference documentation the part of the FAQ related to the guest trick.

                      about the redirect to IGLAccess.igl after successful authentication:
                      according to the log published, it is the case , (INFO: user= [ iglnr=0 ] : user is authenticated implies redirect to /IGLAccess.igl), but for the guest user....which hasn't got any right to follow this resource.
                      the scenario is to let the user authenticated as guest on the ifrst access.
                      after that, when the user tries to reach a protected area, a login screen is displayed, and on a successful authentication,it is redirected to the protected area if it has got access to it; otherwise , the access denied screen is displayed.
                      hope it helps,

                      charles.

                       
                      • chk
                        chk
                        2009-02-27

                        Hi,
                        there it still seems that I misunderstand things.
                        According to your explanations there should happen a redirect to the login page in case an authenticated User tries to access an authorized page for which the user is unauthorized (My scenario: for getting authenticated  a user access a page which is authorized for a guest (IGLAccess.igl), then the "guest" accesses a page which is authorized for a "member"). In my case there is

                         
                        INFO: Server startup in 8634 ms
                        18:28:16,270 DEBUG AccessFilter:438 - uriWithQuery=/IGLAccess.igl
                        18:28:16,270 DEBUG AccessFilter:438 - uriWithQuery=/IGLAccess.igl
                        18:28:16,271 DEBUG AccessFilter:768 - uriWithQuery=/IGLAccess.igl
                        18:28:16,271 DEBUG AccessFilter:768 - uriWithQuery=/IGLAccess.igl
                        18:28:16,287 DEBUG AccessFilter:213 - LAST_ACCESS_DENIED_URI=/IGLAccess.igl
                        18:28:16,287 DEBUG AccessFilter:213 - LAST_ACCESS_DENIED_URI=/IGLAccess.igl
                        25.02.2009 18:28:16 net.sf.jguard.ext.audit.AuditManager addEvent
                        INFO: user is null  :  subject is null  implies  logonProcess phase
                        25.02.2009 18:28:16 net.sf.jguard.ext.audit.AuditManager addEvent
                        INFO: user is null  :  AUTHENTICATION TYPE =FORM implies   authenticate phase 
                        18:28:16,413 DEBUG HttpCallbackHandler:118 - authSchemeItem=FORM
                        18:28:16,413 DEBUG HttpCallbackHandler:118 - authSchemeItem=FORM
                        18:28:16,421 DEBUG LocalLoginContext:171 -  loginModule class net.sf.jguard.ext.authentication.loginmodules.XmlLoginModule in 'login' phase succeed
                        18:28:16,421 DEBUG LocalLoginContext:171 -  loginModule class net.sf.jguard.ext.authentication.loginmodules.XmlLoginModule in 'login' phase succeed
                        18:28:16,422 DEBUG HttpCallbackHandler:118 - authSchemeItem=FORM
                        18:28:16,422 DEBUG HttpCallbackHandler:118 - authSchemeItem=FORM
                        18:28:16,424 DEBUG LocalLoginContext:167 -  loginModule class net.sf.jguard.ext.authentication.loginmodules.JCaptchaLoginModule in 'login' phase is ignored 
                        18:28:16,424 DEBUG LocalLoginContext:167 -  loginModule class net.sf.jguard.ext.authentication.loginmodules.JCaptchaLoginModule in 'login' phase is ignored 
                        18:28:16,424 DEBUG LocalLoginContext:215 -  loginModule class net.sf.jguard.ext.authentication.loginmodules.XmlLoginModule in 'commit' phase succeeed
                        18:28:16,424 DEBUG LocalLoginContext:215 -  loginModule class net.sf.jguard.ext.authentication.loginmodules.XmlLoginModule in 'commit' phase succeeed
                        18:28:16,425 DEBUG LocalLoginContext:215 -  loginModule class net.sf.jguard.ext.authentication.loginmodules.JCaptchaLoginModule in 'commit' phase succeeed
                        18:28:16,425 DEBUG LocalLoginContext:215 -  loginModule class net.sf.jguard.ext.authentication.loginmodules.JCaptchaLoginModule in 'commit' phase succeeed
                        18:28:16,432 DEBUG AccessFilter:696 -  user is authenticated and redirected to ./IGLAccess.igl
                        18:28:16,432 DEBUG AccessFilter:696 -  user is authenticated and redirected to ./IGLAccess.igl
                        25.02.2009 18:28:16 net.sf.jguard.ext.authentication.loginmodules.JCaptchaLoginModule login
                        FEIN: session ID=745F487E0B04D452F8DB56E509FE03F8
                        25.02.2009 18:28:16 net.sf.jguard.ext.authentication.loginmodules.JCaptchaLoginModule login
                        FEIN: service=null
                        25.02.2009 18:28:16 net.sf.jguard.ext.audit.AuditManager addEvent
                        INFO:  user= [  iglnr=0 ] :  user is authenticated  implies  redirect to /IGLAccess.igl
                        18:28:16,553 DEBUG AccessFilter:438 - uriWithQuery=/IGLAccess.igl
                        18:28:16,553 DEBUG AccessFilter:438 - uriWithQuery=/IGLAccess.igl
                        18:28:16,558 DEBUG AccessFilter:768 - uriWithQuery=/IGLAccess.igl
                        18:28:16,558 DEBUG AccessFilter:768 - uriWithQuery=/IGLAccess.igl
                        18:28:16,621 DEBUG AccessFilter:515 - doFilter() -  access authorized to /jserv/IGLAccess.igl
                        18:28:16,621 DEBUG AccessFilter:515 - doFilter() -  access authorized to /jserv/IGLAccess.igl
                        18:28:16,646  INFO TilesRequestProcessor:103 - Tiles definition factory found for request processor ''.
                        25.02.2009 18:28:16 net.sf.jguard.ext.audit.AuditManager addEvent
                        INFO:  user= [  iglnr=0 ] :  subject has got the permission name=permissionFromUser actions=/IGLAccess.igl,ANY,GETpermission build from the user request implies  authorize phase
                        18:28:48,037 DEBUG AccessFilter:438 - uriWithQuery=/members/searchForm.igl
                        18:28:48,037 DEBUG AccessFilter:438 - uriWithQuery=/members/searchForm.igl
                        18:28:48,038 DEBUG AccessFilter:768 - uriWithQuery=/members/searchForm.igl
                        18:28:48,038 DEBUG AccessFilter:768 - uriWithQuery=/members/searchForm.igl
                        18:28:48,056 DEBUG HttpAccessControllerUtils:83 -  permission  name: permissionFromUser
                        scheme: ANY
                        parameters: net.sf.jguard.core.authorization.permissions.URLParameterCollection@196d982
                        pattern: /members/searchForm.igl
                        uri: /members/searchForm.igl
                        description: GETpermission build from the user request
                        is not granted
                        18:28:48,056 DEBUG HttpAccessControllerUtils:83 -  permission  name: permissionFromUser
                        scheme: ANY
                        parameters: net.sf.jguard.core.authorization.permissions.URLParameterCollection@196d982
                        pattern: /members/searchForm.igl
                        uri: /members/searchForm.igl
                        description: GETpermission build from the user request
                        is not granted
                        18:28:48,057 DEBUG AccessFilter:489 -  access denied to /jserv/members/searchForm.igl
                        18:28:48,057 DEBUG AccessFilter:489 -  access denied to /jserv/members/searchForm.igl
                        18:28:48,096 DEBUG AccessFilter:438 - uriWithQuery=/AccessDenied.igl
                        18:28:48,096 DEBUG AccessFilter:438 - uriWithQuery=/AccessDenied.igl
                        18:28:48,097 DEBUG AccessFilter:768 - uriWithQuery=/AccessDenied.igl
                        18:28:48,097 DEBUG AccessFilter:768 - uriWithQuery=/AccessDenied.igl
                        25.02.2009 18:28:48 net.sf.jguard.ext.audit.AuditManager addEvent
                        INFO:  user= [  iglnr=0 ] :  subject hasn't got the permission name=permissionFromUser actions=/members/searchForm.igl,ANY,GETpermission build from the user request implies  accessdenied phase
                        25.02.2009 18:28:48 net.sf.jguard.ext.audit.AuditManager addEvent
                        INFO:  user= [  iglnr=0 ] :  access is denied to/jserv/members/searchForm.igl implies  user is redirected to accessDeniedURI/AccessDenied.igl
                        25.02.2009 18:28:48 net.sf.jguard.ext.audit.AuditManager addEvent
                        INFO:  user= [  iglnr=0 ] : subject is not null and URI/AccessDenied.igl= accessDeniedURI( /AccessDenied.igl) implies  access authorized

                        I still do sth. wrong (most probably), but what?. What are the possible origins to produce this wrong flow? Have I still forgotten to authorize sth?

                        Regards, chk

                         
                        • Charles Lescot
                          Charles Lescot
                          2009-02-27

                          hi,
                          does the IGLAccess.igl page is also granted to the authenticated user?
                          also for the guest?(like implied in your comments)
                          it seems that's not the case because the 'LAST_ACCESS_DENIED_URI' is /IGLAccess.igl in the log you've published...
                          maybe the problem comes from here.....

                          hope it helps,

                          Charles.

                           
                          • chk
                            chk
                            2009-02-27

                            Hi Charles,
                            thanks for the response.
                            /IGLAccess.igl is defined in the JGuardFilter.xml as <indexURI>/IGLAccess.igl</indexURI>. I considered this URI as authorized to every authenticated user/role. Am I wrong?
                            Regards, chk

                             
                          • chk
                            chk
                            2009-02-27

                            Hi Charles,
                            thanks for the response.
                            /IGLAccess.igl is defined in the JGuardFilter.xml as <indexURI>/IGLAccess.igl</indexURI>. I considered this URI as authorized to every authenticated user/role. Am I wrong?
                            Regards, chk

                             
              • Hi Charles,
                I could realizet to make the jguard-struts example run after I realized the the example logs into a file instead of the console. (Which I think is no good idea because from where should somebody new know the filename as well as its location).
                Anyway. the example's .war did not contain all libs. That was my problem.
                Now I do come back to your question whether my application works as your example (vice versa, respectively).
                And I can say, that it works the same way.
                And I can also say that there is a certain discrepancy between the understanding of the login process.
                And I now can see how to solve my problem.
                I have to make the filter redirecting to the login page instead of an access-denied page. That way, in case I am not yet logged in with a role authorized for that page, I am redirected to the login page. After a successful login I will be redirected to the page which I wanted to access automatically.

                I think, I found a solution to my problem.
                Regards, canelli

                 
    • chk
      chk
      2009-02-13

      Hi Charles,
      here is a log file of what I have done.
      the 1st login happend with a valid user, one different than the guest account. For your info, the guest account has a public credential called iglnr which has the value 0.
      Here is the logging file:
      09.02.2009 17:41:57 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO: user is null  :  subject is null  implies  logonProcess phase
      09.02.2009 17:41:57 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO: user is null  :  AUTHENTICATION TYPE =FORM implies   authenticate phase 
      09.02.2009 17:42:22 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO: user is null  : authentication failed implies  redirect to /AuthenticationFailed.igl
      09.02.2009 17:42:22 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO: user is null  :  NOT BASIC AUTHENTICATION - user is not authenticated  implies  redirect to /jserv/AuthenticationFailed.igl
      09.02.2009 17:42:22 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO: user is null  :  subject is null  implies  logonProcess phase
      09.02.2009 17:42:22 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO: user is null  :  AUTHENTICATION TYPE =FORM implies   authenticate phase 
      09.02.2009 17:42:29 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO:  user= [  iglnr=0 ] :  user is authenticated  implies  redirect to /AuthenticationFailed.igl
      09.02.2009 17:42:29 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO:  user= [  iglnr=0 ] : subject is not null and URI/AuthenticationFailed.igl= authenticationFailedURI( /AuthenticationFailed.igl) implies  access authorized

      the 2nd run of login is happend just after the 1st with the same credentials as the 1st one. The public credential of the valid account has the value 103 :
      09.02.2009 17:48:29 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO:  user= [  iglnr=0 ] :  uri(/Authenticated.igl)=logonProcessURI(/Authenticated.igl) implies  logonProcess phase
      09.02.2009 17:48:29 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO:  user= [  iglnr=0 ] :  AUTHENTICATION TYPE =FORM implies   authenticate phase 
      09.02.2009 17:51:36 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO:  user= [  iglnr=103 ] :  user is authenticated  implies  redirect to /IGLAccess.igl
      09.02.2009 17:51:36 net.sf.jguard.ext.audit.AuditManager addEvent
      INFO:  user= [  iglnr=103 ] :  subject has got the permission name=permissionFromUser actions=/IGLAccess.igl,ANY,GETpermission build from the user request implies  authorize phase

      To me it seems that jguard ignores the given credentials in the 1st run. And only after the guest principal was available only then the other valid account could get authenticated.
      I guess there must be some wrong configurations in my application, isnt it?
      Please help.
      Regards chk

       
      • chk
        chk
        2009-02-13

        The behaviour in the login what I just have posted contradicts with your documentation:
        4. The filter verifies if there the request contains the login and password data. If not, the jGuard uses GUEST/GUEST to authenticate as a guest.
        It contradicts because I had delivered a valid user and password ... strange ......

        Regards, chk