Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: RCP client; AuthorizationCredentialsNotFoundException

  1. #11

    Default

    Actually, I believe it is the authorization part that is failing, not authentication.
    Last edited by mecode; Mar 13th, 2007 at 08:56 AM.

  2. #12
    Join Date
    Mar 2007
    Posts
    6

    Default Authentication object not getting into SecurityContextHolder

    On the server-side I "disabled" authorization by commenting out all method level role entries. I then added an AOP logging to all methods and in that AOP logging I do a "SecurityContextHolder.getContext()" ... the SecurityContext is null.

    So, the RCP client appears to be putting the Authentication object into the HTTP message but the server-side does not appear to be putting it into the SecurityContextHolder (or at least not the SecurityContextHolder that the AOP logging class has access to).

    I don't know how exactly the Authentication object included with the HTTP from the RCP Client is supposed to be handled on the server-side but I thought it was supposed to be put into the thread-local SecurityContrextHolder and accessible in the code.

    Thanks,

    Ferris.

  3. #13
    Luke Taylor is offline Senior Member Acegi Security System TeamSpring Team
    Join Date
    Aug 2004
    Location
    Glasgow, Scotland
    Posts
    3,449

    Default

    I'm not familiar with the Spring RCP project, but this is what I would do:

    1. Get the source for whatever RCP stuff you are using.
    2. Add it to your IDE.
    3. Run your server in debug mode.
    4. Put a breakpoint at some point in the server side where you know it will be hit.
    5. Look back up the stack trace to the appropriate RCP class where the invocation begins on the server side.
    6. Browse to the source file and put a breakpoint there.
    7. Run the client again.
    8. Debug the behaviour from there.

  4. #14

    Default

    Quote Originally Posted by Luke View Post
    I'm not familiar with the Spring RCP project, but this is what I would do:

    1. Get the source for whatever RCP stuff you are using.
    2. Add it to your IDE.
    3. Run your server in debug mode.
    4. Put a breakpoint at some point in the server side where you know it will be hit.
    5. Look back up the stack trace to the appropriate RCP class where the invocation begins on the server side.
    6. Browse to the source file and put a breakpoint there.
    7. Run the client again.
    8. Debug the behaviour from there.
    We aren't using Spring RCP. It's an Eclipse RCP app.

    Maybe the following log entries on the client side will spur some thoughts. Notice that we are hitting two different URLs:

    13:05:04.212 [ModalContext] DEBUG o.a.providers.ProviderManager - Authentication attempt using org.acegisecurity.providers.rcp.RemoteAuthenticati onProvider
    13:05:04.232 [ModalContext] DEBUG o.s.r.h.SimpleHttpInvokerRequestExecutor - Sending HTTP invoker request for service at [http://localhost:4949/-bpass/nonsecu...cationManager], with size 374
    13:05:04.583 [ModalContext] DEBUG o.s.c.s.ClassPathXmlApplicationContext - Publishing event in context [org.springframework.context.support.ClassPathXmlAp plicationContext;hashCode=26578114]: org.acegisecurity.event.authentication.Authenticat ionSuccessEvent[source=org.acegisecurity.providers.UsernamePasswor dAuthenticationToken@709b0fc7: Username: nbdm52r; Password: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: ROLE_bpass_maint.Roles.ESM.asm, ROLE_ENTERPRISE_tmrdomain_access, ROLE_epclass_access.Roles.ESM.asm, ROLE_epclass_class_def_maint.Roles.ESM.asm, ROLE_epclass_classification_maint.Roles.ESM.asm, ROLE_epclass_user_class_maint.Roles.ESM.asm, ROLE_epclass_ep_cdi_uat.Roles.EPClassification.asm , ROLE_epclass_maint.Roles.ESM.asm, ROLE_epclass_maint_cdmaint.Roles.EPClassification. asm, ROLE_eptap_basic.Roles.ESM.asm, ROLE_eptap_troubleshoot.Roles.ESM.asm, ROLE_eptap_ep_delete.Roles.ESM.asm, ROLE_eptap_sysadmin.Roles.ESM.asm, ROLE_eswd_access.Roles.ESM.asm, ROLE_jboss_admin.Roles.ESM.asm, ROLE_mobile_client_options.Roles.ESM.asm, ROLE_pkgauto_access.Roles.ESM.asm, ROLE_rds_access.Roles.ESM.asm, ROLE_rds_file_input_access.Roles.ESM.asm, ROLE_self_svc_main_access.Roles.ESM.asm, ROLE_webreports_access.Roles.ESM.asm, ROLE_INTERNATIONAL_tmrdomain_access, ROLE_PACKAGER_tmrdomain_access, ROLE_SERVER_tmrdomain_access, ROLE_profile_group_access.Roles.DBK.asm, ROLE_profile_group_access.Roles.IDB.asm, ROLE_ATM_tmrdomain_access, ROLE_admin_access.Roles.ESM.asm, ROLE_sig_maint_access.Roles.ESM.asm, ROLE_endpoint_access.Roles.DCP.asm, ROLE_package_access.Roles.DCP.asm, ROLE_profile_group_access.Roles.CDI.asm, ROLE_profile_group_access.Roles.CRD.asm, ROLE_cretssales_profile_group_access.Roles.CRE.asm , ROLE_profile_group_access.Roles.CRE.asm, ROLE_cretssite_profile_group_access.Roles.CRE.asm, ROLE_profile_group_access.Roles.DCP.asm, ROLE_profile_group_access.Roles.ESM.asm, ROLE_profile_group_access.Roles.INTERNATIONAL.asm, ROLE_profile_group_access.Roles.MBNA.asm, ROLE_profile_group_access.Roles.WinTel_Servers.asm , ROLE_profile_group_access.Roles.WORKSTATION.asm, ROLE_bpass_access.Roles.ESM.asm]
    13:05:04.583 [ModalContext] DEBUG o.s.r.h.SimpleHttpInvokerRequestExecutor - Sending HTTP invoker request for service at [http://localhost:4949/-bpass/secure/bpass_controller], with size 506
    java.lang.reflect.InvocationTargetException
    at com.company.esm.bpa.client.bpass.wizards.LoginWiza rd$1.run(LoginWizard.java:95)
    at org.eclipse.jface.operation.ModalContext$ModalCont extThread.run(ModalContext.java:113)
    Caused by: org.acegisecurity.AuthenticationCredentialsNotFoun dException: An Authentication object was not found in the SecurityContext
    Last edited by mecode; Mar 13th, 2007 at 01:05 PM.

  5. #15

    Default

    Attached are some relevant log entries from the server.
    Attached Files Attached Files

  6. #16

    Default

    We got it to work to a certain degree, but here is the main question we have now: is there any way to use an RCP client with Acegi so it can take advantage of session integration or remember me services so it doesn't have to reauthenticate for every request?

  7. #17
    Luke Taylor is offline Senior Member Acegi Security System TeamSpring Team
    Join Date
    Aug 2004
    Location
    Glasgow, Scotland
    Posts
    3,449

    Default

    You can configure the authentication provider on the server side to use a cache so you don't have to hit the database every time.

  8. #18

    Default

    Quote Originally Posted by Luke View Post
    You can configure the authentication provider on the server side to use a cache so you don't have to hit the database every time.
    Ouch...that's what we had before. Thought we were doing something wrong.

  9. #19
    Luke Taylor is offline Senior Member Acegi Security System TeamSpring Team
    Join Date
    Aug 2004
    Location
    Glasgow, Scotland
    Posts
    3,449

    Default

    Quote Originally Posted by mecode View Post
    Thought we were doing something wrong.
    Why did you think that? It's provided as part of the framework

    http://acegisecurity.org/docbook/ace...rovider-config

    It's pretty standard to cache authentication information if your client's interaction with the server is stateless.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •