I have a CDI -> EJB App.
I do the security in the past with JBoss j_security.
My security with Shiro works.
But my only problem is how can I get SessionContext in my EJB?
With Jboss Security I got the username, who login in the location with:
SessionContext sessionContext;
String email = sessionContext.getCallerPrincipal().getName();
Now I want to get the the username in my EJB.
How ca I set the username with SessionContext?
Thank you for help
This is a bit tricky, and it also depends on the version of JBoss that you are using. In the AS 7.x and EAP 6.x range this can't really be done by using public APIs because of several bugs.
In order to make the sessionContext aware of the user name and roles you can use JBoss specific code like I used here: https://github.com/javaeekickoff/jboss-as-jaspic-patch/commit/d691fd4532d9aeae6136e3adc2537ff81c525673
It should be something like;
SecurityContext context = SecurityActions.getSecurityContext();
context.getUtil().createSubjectInfo(new SimplePrincipal(userName),
null,
someSubject
);
Take a look at the rest of the file to see how someSubject should be created and populated.
Unfortunately for the mentioned JBoss versions #RolesAllowed will never work, since JBoss doesn't take over the already authenticated identity from the local caller, but will always consult a JBoss specific "security domain" just prior to calling the actual bean. Of course it known nothing about Shiro.
Related
I implemented an authentication mechanism similar to CustomHeaderHttpAuthenticationMechanism in https://github.com/wildfly-security-incubator/elytron-examples/tree/master/simple-http-mechanism, using PasswordGuessEvidence and also the other Callbacks mentioned in the example. Reason for the custom mechanism is that beside a simple credential check we need also to validate more constraints to check if a user is validated.
Stepping through this authentication mechanism looks quite good, the authenticationComplete method is called and also the authorizeCallback is successful. However, when accessing an EJB via a resteasy endpoint (EJB is annotated with #SecurityDomain and #RolesAllowed...) the SimpleSecurityManager.authorize method fails because the securityContext.getUtil method neither provides a principal nor something else. If accessing a method annotated by #PermitAll it is successful.
I guess the principal should be created by the ServerAuthenticationContext when working through the different callbacks, right?
How do I manage that the SimpleSecurityManager can recognize the principal, would I need to create it in my authentication mechanism, and how?
In this case it sounds like your EJB deployment has not been mapped to the WildFly Elytron security domain so is still making use of PicketBox security in the EJB tier which is why you are not seeing the identity already established.
Within the EJB subsystem you can also add an application-security-domain mapping to map from the security domain specified in the deployment to the WildFly Elytron security domain.
FYI at some point in the future when we are ready to remove PicketBox from the server these additional mappings will no longer be required, they are just unfortunately needed at the moment whilst we have both solutions in parallel.
I try EJB invocations from a client to a server, they are actually same copied ear files each other and on same machine.
I think that I must set "distinct-name" in somewhere, but I can not find it.
WildFly Developer Guide - EJB invocations from a remote client using JNDI:
distinct-name : This is a WildFly-specific name which can be optionally assigned to the deployments that are deployed on the server. More about the purpose and usage of this will be explained in a separate chapter. If a deployment doesn't use distinct-name then, use an empty string in the JNDI name, for distinct-name
Where is "a separate chapter"?
Set <distinct-name> attribute in jboss-app.xml(EAR) or jboss-ejb3.xml(WAR/EJB jar).
In a Wildfly 8.1.0.Final we deploy:
our own CRM-webapp (Seam2/JSF1.2)
camunda-webapp 7.3.0
camunda-engine 7.3.0 as a module (shared engine)
custom engine-plugin to enable camunda-engine to use the user/group-store of our CRM
We display camunda tasklist in an iframe inside our CRM.
This setup runs fine so far, but we have to login twice.
So we need SSO, but cannot establish AD/LDAP, like in camunda-sso-jboss example.
I thought of Wildfly's JAAS and SSO capabilities, but i'am not sure, if camunda-webapp supports JAAS-authentication.
I think the security-domain configuration in jboss-web.xml is just generated by a maven archetype and has no effect on the camunda-webapp, is that right? I changed that configuration and it had no effect at all.
Can someone give me a hint, where i should hook into camunda-webapp or if it is possible at all?
Ok, i have a first success.
I changed org.camunda.bpm.webapp.impl.security.auth.Authentications.getFromSession to accept HttpServletRequest as parameter instead of HttpSession (called from AuthenticationFilter.doFilter). If the session contains no Authentications, i try to pull the Principle from the request and if one exists, i log em in silently (copied most from UserAuthenticationResource.doLogin).
Then i have a very simple webapp ("testA") with only one JSP and Basic Authentication. Both camunda-webapp and testA have the same security-domain configured, and the host in the undertow-subsystem has the "single-sign-on"-setting.
Now i can login into /testA, then call /camunda in another tab without further authentication.
The code has to be improved a lot. If everythink works fine, i'll post the details.
If someone thinks this is a wrong approach, please let me know ;-)
I am using httpinvoker in JBoss 4.0.4 (little old) for EJB invocations.
Since there are so many clients that make calls to my server, I want to identify the clients for each call in server.
Is there a way to do this with JBoss httpinvoker?
I could imagine adding a header to identify my client in each HTTP request, but cannot find a way to add a header in httpinvoker.
Auditing builds on a name, and thus on an authentication scheme somehow.
Therefore I suggest using the standard client authentication infrastructure to solve your problem. This works for RMI as well (it's not bound to HTTP), and the user ID is even passed down into your EJBs.
Server
Put the EJB in a security-domain (ejb.jar: META-INF/jboss.xml)
You could use the application-policy other which just the UsersRolesLoginModule (conf/login-config.xml); this is the default policy, it's already configured.
Add users.properties and roles.properties to your ejb.jar file (top level package): These are used by the UsersRolesLoginModule
For each user, add his name and a (dummy) password to users.properties
Client
Create a callback class which implements a javax.security.auth.callback.CallbackHandler: This callback is used, when the authentication needs the user and the password.
Create a javax.security.auth.login.LoginContext; pass the callback handler as the 2nd argument; call login() on the instance of the LoginContext
Connect normally to the EJB server using an InitialContext
Add -Djava.security.auth.login.config=.../jboss-4/client/auth.conf when you start the client
This way a user ID is passed from the client to the EJB (as part of the standard authentication process). Now, in the EJB methods, you can get the user ID by calling getCallerPrincipal() on the SessionContext instance. I have tested this against JBoss 4.2.3
Additional information: JBoss client authentication
Addendum 1:
Using RMI or HTTP, the password is not transported in a secure way. In this case just use a dummy password, this is OK for auditing.
On the other hand, if you use RMI over SSL or HttpInvoker over HTTPS, you could change to a real and secure authentication quickly.
Addendum 2:
I am not sure, if it works without defining roles. Possibly you have to
Add a line in roles.properties for each user: Add a connect role, for example
Add role definitions in ejb-jar.xml as well: security-role-ref for each EJB, and security-role and method-permission in the assembly-descriptor
Update
As there is already a login module, there might be another possibility:
If you have the source code of the login module, you could possibly use another TextCallback to get additional information from the client (in your case a user ID). The information could be used to create a custom Principal. Within the EJB, the result of getCallerPrincipal() could be cast to the custom principal.
In Jboss 5.1 the Profile Service does what the Deployment Service was doing in Jboss 4.x.In Jboss 4.x I was using the Deployment Service to create a datasource "on-the-fly" and I was wondering if I could do the same thing using the Profile Service (since Deployment Service doesn't exist any more in Jboss 5.x).
Does anyone know a practical guid on using ProfileService?
Thank you ,
Regards.
I don't know of any guide but I can provide you with my experience using the Profile Service and a few links to JBoss wiki pages on this topic. I'd like to post more links but the spam protection doesn't allow me to post more than two, but you should easily find the other pages in the wiki on the ProfileService. Don't be suprised in case you don't find much, there isn't more.
ProfileService ManagementView
http://community.jboss.org/wiki/ProfileServiceManagementView
ProfileService DeploymentTemplates
http://community.jboss.org/wiki/ProfileServiceDeploymentTemplates
There you'll find usefull information about the ProfileService but no detailed information is available in the jboss wiki as far as I can tell.
In order to create Datasources on the fly you can use the DeploymentTemplates (also for creating message queues and topics) The last link provides you with information on how to use the templates but not with all the template names and their properties. You can list them programatically though.
// Get all Templates
for(String template : mgtView.getTemplateNames())
{
System.out.println("=========================================");
System.out.println("Listing properties for template: "+template);
DeploymentTemplateInfo info = mgtView.getTemplate(template);
for(String prop : info.getProperties().keySet())
System.out.println("- "+prop);
}
In order to get the ManagementView (mgtView) from an external java programm you can use something similiar to this:
// set security policy
System.setProperty("java.security.policy", "<path_to_policy_file>");
System.setSecurityManager( new RMISecurityManager() ) ;
// set initial context properties
Hashtable<String, String> env = new Hashtable<String, String>();
env.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
env.put("java.naming.provider.url","jnp://localhost:1099");
env.put("java.naming.factory.url.pkgs","org.jboss.naming:org.jnp.interfaces");
ctx = new InitialContext(env);
// login to JBoss
SecurityClient client = SecurityClientFactory.getSecurityClient();
client.setSimple("admin", "admin");
client.login();
// get ProfileService and ViewManager
ProfileService ps = (ProfileService) ctx.lookup("ProfileService");
mgtView = ps.getViewManager();
What you want to get is the Java Naming Conext (InitialContext). In order to do that you'll need a security policy (you can use the java.policy file which is located in JBOSS_HOME/server/SERVER_DIR/conf/),security manager and environment properties to get the context. The java.naming.provider.url specifies the location of the JBoss naming service (default port is 1099).
Usually you would have to authenticate at this point which is done with the SecurityClient.
Finally you can use the context to grap the ProfileService.
At this point most of the anoying stuff is done und you can start playing around.
getViewManager() returns the ViewManager with which you can create datasources on the fly and getDeploymentManager() will give you the DeploymentManager with which you can deploy, undeploy, start, stop applications and other deployments.
The libraries you'll need to do that are located in
JBOSS_HOME/client
JBOSS_HOME/lib
JBOSS_HOME/common/lib
I've read several times that including the jbossall-client.jar in the client directory should be enough but that's actually not true. You need libraries from all three directories as far as I can tell (couldn't do it without referencing all of them at least). I haven't figured out which exact jars you need though...
IMPORTANT: The ProfileService in Jboss 5 Community Edition has some bugs though which got fixed in JBoss 6. I'd either suggest using a newer JBoss version or the Enterprise Edition.