Actually, I believe it is the authorization part that is failing, not authentication.
Actually, I believe it is the authorization part that is failing, not authentication.
Last edited by mecode; Mar 13th, 2007 at 08:56 AM.
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.
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.
Attached are some relevant log entries from the server.
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?
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.
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.