Did you enable the security for your application?
Also you should show how you have configured the outbound connection
Yes i've enabled security policy in jboss-app.xml
<jboss-app> <security-domain>SecurityPolicy</security-domain> ....
And also in standalone.xml remoting configuration is as below:
<security-realm name="ejb-security-realm"> <server-identities> <secret value="ZGVmYXVsdHVzZXI="/> </server-identities> </security-realm> .... .... <subsystem xmlns="urn:jboss:domain:remoting:1.1"> <connector name="remoting-connector" socket-binding="remoting"/> <outbound-connections> <remote-outbound-connection name="remote-ejb-connection" outbound-socket-binding-ref="remote-ejb" username="ejb" security-realm="ejb-security-realm"> <properties> <property name="SASL_POLICY_NOANONYMOUS" value="false"/> <property name="SSL_ENABLED" value="false"/> </properties> </remote-outbound-connection> </outbound-connections> </subsystem> ..... <security-domain name="SecurityPolicy" cache-type="default"> <authentication> <login-module code="Remoting" flag="optional"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> <login-module code="org.jboss.security.ClientLoginModule" flag="required"> <module-option name="restore-login-identity" value="true"/> </login-module> <login-module code="xxx.xxx.xxx.CustomLoginCheck" flag="required"> <module-option name="unauthenticatedIdentity" value="defaultuser"/> </login-module> </authentication> </security-domain>
<jboss-ejb-client xmlns:xsi="urn:jboss:ejb-client:1.0" xsi:noNamespaceSchemaLocation="jboss-ejb-client_1_2.xsd"> <client-context> <!-- By default LocalEJBReceiverPreferringDeploymentNodeSelector.class is used Node Selector--> <ejb-receivers> <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection"/> </ejb-receivers> <clusters> <cluster name="ejb" username="ejb" security-realm="ejb-security-realm"> <connection-creation-options> <property name="org.xnio.Options.SSL_ENABLED" value="false"/> <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false"/> </connection-creation-options> </cluster> </clusters> </client-context> </jboss-ejb-client>
Do i need any additional configuration in order to propagate the security credentials.
1 of 1 people found this helpful
Despite what you may have read elsewhere never ever ever ever use the ClientLoginModule in a security domain that is used to secure access to an application. In short it leaks security contexts in certain circumstances.
To propagate an identity from one server to another you should have a look at the ejb-security-interceptors quickstart, this quick start demonstrates how interceptors can be used to pass the name of the user from the client side to the server side of the call along with the EJB invocation and how login modules can verify this user and switch the identity for the call.
Thanks darranl for your reply,
I looked into the ejb-security-interceptors quickstart.
I've following questions related to the example,
1. In the example @ DelegationLoginModule, No password validation happens for delegation request (the delegation credentials checks against the user@realm in property and it returns the status).
2. The security information along with realm gets propagated when i do remote invocation and it is fine. But the mater is the password gets encrypted. For eg: My Password is 'defaultuser' gets encrypted as 'bb5331d1-5630-4687-8137-3fd8f7b8e74a'. It changes often. What's the algorithm behind this, so that i can decrypt it and validate.
3. In the thread https://community.jboss.org/thread/200905 Jaikiran Pai said that there is no way to dynamically configured user for remote invoking from server to server. Now I'm hard-coring the values in standalone.xml. Is there any other work around to do that programatically.
Thanks in advance,
1 of 1 people found this helpful
1 - Yes that is correct, the client server has already authenticated against the second server so the quick start is demonstrating trust i.e. the first server is trusted to ask for requests to be executed as a different user
2 - That is not a password, that is just a place holder we use to work around a JAAS / realm integration issue. You will need the realm that secures the incoming connection to be configured to delegate to JAAS.
3 - The solution is to use the quickstart approach with the interceptors and login module to switch the identity for the call.