[ https://issues.jboss.org/browse/WFLY-11587?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-11587: ----------------------------------------- [~manovotn] [~dlofthouse] I added a simple test of injecting the Principal built-in bean to my PR for this at https://github.com/wildfly/wildfly/pull/11996. Unfortunately it's showing what looks like a pre-existing issue when the test is run with a security manager enabled: {code} Caused by: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader") at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:84) at org.jboss.as.security.service.SimpleSecurityManager.getCallerPrincipal(SimpleSecurityManager.java:136) at org.jboss.as.weld.services.bootstrap.WeldSecurityServices.getPrincipal(WeldSecurityServices.java:84) at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:41) at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:30) at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:38) at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106) at org.jboss.weld.security.Principal$$Proxy$_$$_Weld$Proxy$.getName(Unknown Source) at org.jboss.as.test.integration.weld.builtin.CDIResource.getMessage(CDIResource.java:40) at org.jboss.as.test.integration.weld.builtin.CDIResource$Proxy$_$$_WeldClientProxy.getMessage(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399) at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363) at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439) ... 57 more Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader") at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191) at org.jboss.security.identity.plugins.IdentityFactory.loadClass(IdentityFactory.java:91) at org.jboss.security.identity.plugins.IdentityFactory.createPrincipal(IdentityFactory.java:49) at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:80) ... 80 more {code} I don't know whether the spec has anything to say regarding any permissions that should be required in order to inject a Principal. If it says they shouldn't be required or is silent on the topic and we think they should not be necessary, then we are missing a privileged block. Otherwise I doubt what's being thrown here is what we'd want. If some permission is needed, checking for something more related to the use case (probably something new) would be better, and if that permission check passes then make the call in a privileged block. -- This message was sent by Atlassian Jira (v7.12.1#712002)