I am working on an EJB application. I have to apply role based security on session bean(EJB3) methods, for which I tried annotating the session bean method with "#RolesAllowed" as below,
For creating User, groups and roles i am using jazn-data.xml as below,
After the deploying the EJB and running the application, security does get applied and throws an exception [EJB:010160]Security Violation: User: 'XXX' has insufficient permission to access EJB
After Adding the weblogic ejb deployment descriptor as below,
<?xml version = '1.0' encoding = 'windows-1252'?>
<weblogic-ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.1/weblogic-ejb-jar.xsd"
xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar">
<weblogic-enterprise-bean>
<ejb-name>ApplicationFacade</ejb-name>
<stateless-session-descriptor/>
<enable-call-by-reference>true</enable-call-by-reference>
</weblogic-enterprise-bean>
<security-role-assignment>
<role-name>PVUser</role-name>
<principal-name>pv</principal-name>
</security-role-assignment>
<security-role-assignment>
<role-name>PRUser</role-name>
<principal-name>pr</principal-name>
</security-role-assignment>
</weblogic-ejb-jar>
It starts working as expected.
My question is related to weblogic ejb deployment descriptor(weblogic-ejb-jar.xml), do I have to make an entry for each user (pricipal-name), each time I am adding a new user or is there a way by which i can map a user-groups?
Also let me know if I have missed any other configuration required to add permissions.
The Answer is yes,
and what you need to do is creating a group named xxx by login to the
weblogic console( modify within the Security Realms panel)
then adding all of the user to the group named xxx
lastly in the weblogic ejb deployment descriptor you just need to
specify the group name as
< principal-name >xxxgroup name < / principal-name >
as a result, every member within the group would share the
permission.
Related
I am using WebSphere 8.5.5.18.
As of now I'm using Component-Managed Authentication Alias for my DataSource. But I want to use Container-Managed instead. When I just change the Security settings in Data Sources → Security settings I am getting error in logs. It is unable to fetch records.
Exception Stacktrace:
Check the SQL Statement (preparation failed).
--- Cause: java.sql.SQLException: [jcc][t4][10205][11234][3.72.54] Null userid is not supported. ERRORCODE=-4461, SQLSTATE=42815 DSRA0010E: SQL State = 42815, Error Code = -4,461
at org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.doTranslate(SQLStateSQLExceptionTranslator.java:97)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:72)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80)
at org.springframework.orm.ibatis.SqlMapClientTemplate.execute(SqlMapClientTemplate.java:212)
at org.springframework.orm.ibatis.SqlMapClientTemplate.queryForObject(SqlMapClientTemplate.java:271)
Basically the database is not being accessed properly when settings are changed from Component-Managed Authentication to Container-Managed Authentication alias.
When I run with Component-Managed Authentication, its working fine.
Does changing security setting to Container Managed Authentication alias, require some other/additional setting/changes? Or do I need to change my underlying Spring ibatis code to make it work?
Any help on configuring/implementing Container-Managed Authentication Alias in websphere would be appreciated.
Container-managed authentication applies when your code (or any third party code that executes upon its behalf) looks up the data source with a resource reference that specifies the resource authentication as container or leaves resource authentication unspecified, in which case it defaults to container.
Component-managed authentication applies when your code (or any third party code that executes upon its behalf) looks up the data source without a resource reference, or uses a resource reference that specifies the resource authentication as application.
Here are some examples of resource references that use container authentication:
// resource injection can be used on a web component (servlet) or ejb component
#Resource(name = "java:comp/env/jdbc/ds1ref", lookup = "jdbc/ds1", authenticationType = Resource.AuthenticationType.CONTAINER)
DataSource ds1;
#Resource(name = "java:comp/env/jdbc/ds2ref", lookup = "jdbc/ds2")
DataSource ds2;
...
// code that looks up one of the above resource references
DataSource ds = InitialContext.doLookup("java:comp/env/jdbc/ds1ref");
Here is an example of a resource reference defined within a web.xml deployment descriptor:
<resource-ref>
<res-ref-name>java:comp/env/jdbc/ds3ref</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<lookup-name>jdbc/ds3</lookup-name>
</resource-ref>
If third party code, such as Spring, is looking up a data source on your behalf and you would like it to use container authentication, you will need to define a resource reference with container managed authentication, such as shown above in the examples, and supply its resource reference name to the third party software in place of however you are doing so currently. If you are unsure where this is done, it might help to search for occurrences of the configured JNDI name of the WebSphere data source within the application.
I am running a Spring-boot application which authenticates users via our internal LDAP with spring-security-ldap.
By default it binds with LDAP anonymously.
Property 'userDn' not set - anonymous context will be used for read-write operations
But I want the first bind to be with current username.
Where should I specify the userDn attribute?
Thank you for your advice
When using spring ldap maybe you started from one many tutorials on the web but main of them uses embedded ldap server; embdedded server uses ldif file and doesn't need the manager credetials.
When connecting to an external ldap server you need to specify userDn setting it via managerDn method. Here the snippet of code
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
auth.ldapAuthentication().contextSource().managerDn("uid=admin,ou=system")
.managerPassword("secret")
.......
}
Obviously you need to provide also all the other infos like url, port, etc (and userSearchBase like mvreijn told).
I am not the most knowledgeable person regarding Spring-boot, more so regarding LDAP.
That said, your LDAP configuration properties should be mentioned in your application.properties file and are named spring.ldap.*.
They are mentioned in the documentation here.
When initializing your authentication provider, you can pass important properties like the Base DN (root to search from) and the filter using:
.userSearchBase("ou=<your users container>").userSearchFilter("(uid={0})")
Most likely, your search filter will be uid={0} or cn={0}.
I followed the steps in https://github.com/watson-developer-cloud/spring-boot-starter to try an call the Watson Conversation(Assistant) service in a Spring boot application, however I am getting this error:
*************************** APPLICATION FAILED TO START
Description:
Field service in application.ConverseApiBinding required a bean of
type 'com.ibm.watson.developer_cloud.conversation.v1.Conversation'
that could not be found.
Action:
Consider defining a bean of type
'com.ibm.watson.developer_cloud.conversation.v1.Conversation' in your
configuration.
Is there thing else I need to do apart from adding dependencies (I used maven) and
#Autowired
protected Conversation service;
The service url and credentials are provided in the VCAP_SERVICES environment variable.
You need to have something in your application properties file to signal that the conversation bean should be created. Normally this would be the service credentials.
In the case where the service credentials come from VCAP_SERVICES, you can simply specify
watson.conversation.enabled=true
in your application properties file. That should trigger the creation of the bean.
I have a web app running in Tomcat correctly that I want to run on the new OpenLiberty server, the app is starting correctly inside OpenLiberty but at the moment of the database connection initiation is throwing the following exception:
[Default Executor-thread-15] 2018-03-15 15:02:30 ERROR TomcatConnectionManager:41 - Loading jdbc/mysql/myaap failure
javax.naming.NameNotFoundException: java:/comp/env
at com.ibm.ws.jndi.url.contexts.javacolon.internal.JavaURLName.<init>(JavaURLName.java:83)
at com.ibm.ws.jndi.url.contexts.javacolon.internal.JavaURLNameParser.parse(JavaURLNameParser.java:39)
at com.ibm.ws.jndi.url.contexts.javacolon.internal.JavaURLNameParser.parse(JavaURLNameParser.java:60)
at com.ibm.ws.jndi.url.contexts.javacolon.internal.JavaURLContext$NameUtil.<init>(JavaURLContext.java:474)
at com.ibm.ws.jndi.url.contexts.javacolon.internal.JavaURLContext.lookup(JavaURLContext.java:321)
at com.ibm.ws.jndi.url.contexts.javacolon.internal.JavaURLContext.lookup(JavaURLContext.java:370)
at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
The above exception is thrown during the lookup phase:
Context initContext = new InitialContext();
Context envContext = (Context) initContext.lookup("java:/comp/env");
Is there any way to make it work on OpenLiberty doing less changes possible?
On OpenLiberty the equivalent lookup would look like this:
Context initContext = new InitialContext();
Context envContext = (Context) initContext.lookup("java:comp/env");
The key is that you need to use java:comp/... instead of java:/comp/...
The reason why Tomcat is different than Liberty is because Tomcat is just a servlet container and Liberty conforms to the full Java EE specification.
According to section EE.5.2.2 of the Java EE 7 spec:
The application component’s naming environment is composed of four logical
namespaces, representing naming environments with different scopes. The four
namespaces are:
java:comp – Names in this namespace are per-component (for example, per enterprise
bean). Except for components in a web module, each component gets
its own java:comp namespace, not shared with any other component. Components
in a web module do not have their own private component namespace.
See note below.
java:module – Names in this namespace are shared by all components in a
module (for example, all enterprise beans in a single EJB module, or all components
in a web module).
java:app – Names in this namespace are shared by all components in all modules
in a single application, where “single application” means a single deployment
unit, such as a single ear file, a single module deployed standalone, etc.
For example, a war file and an EJB jar file in the same ear file would both have
access to resources in the java:app namespace.
java:global – Names in this namespace are shared by all applications deployed
in an application server instance. Note that an application server instance
may represent a single server, a cluster of servers, an administrative
domain containing many servers, or even more. The scope of an application
server instance is product-dependent, but it must be possible to deploy multiple
applications to a single application server instance.
Had a similar problem going between WebSphere and Tomcat. I'm developing and testing on a Tomcat server and using utilities I can't change that handle the DB connection to our DB2. On WebSphere it uses a constant set to "jdbc/COMPDB2" to retrieve the DataSource when I configure Tomcat and my Web.xml file it resolves to "java:comp/env/jdbc/SFCCDB2"
My work around for on local work space it to add a listener to copy the resource to the level in the InitialContext. I'm not very experienced with the server side of things but this is working so far using TomEE 7.0.81.
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/SFCCDB2");
javax.naming.Context envCtx = (javax.naming.Context) ctx.lookup("java:comp/env");
try{
/*
Added this because after redeploying code to the server it would error
connecting to the DB with an SQLException Datasource is closed
*/
DataSource dataSource = (DataSource) ctx.lookup("jdbc/COMPDB2");
ctx.destroySubcontext("jdbc");
} catch (NamingException e){
//Doesn't exist; safe to just add
}
ctx.createSubcontext("jdbc");
ctx.bind("jdbc/COMPDB2", ds);
ctx.close();
I am using jmeter jms point to point queue for load testing.
But I am getting the following error:
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed]
I am using jmeter 2.11 version
I add user name and password in jndi properties. But still it is not working. Here is the configuration i am using:
QueueConnectionFactory: RemoteConnectionFactory
initial context factory: org.jboss.naming.remote.client.InitialContextFactory
url : remote://localhost:4447
JNDI Prpperties:
username: ..............
password: ...........
Your Jndi properties seem wrong, check this:
http://docs.oracle.com/cd/E19182-01/820-7853/ghyco/index.html
Login / password props are :
java.naming.security.principal
The identity of the principal for authenticating the caller to the service. For more information, see the Java API documentation for javax.naming.Context.SECURITY_PRINCIPAL.
java.naming.security.credentials
The credentials of the principal for authenticating the caller to the service. For more information, see the Java API documentation for javax.naming.Context.SECURITY_CREDENTIALS.
I have encountered similar problem while using jmeter for solace, hope this help to someone having similar issue.
For solace jms testing need to use jndi properties since there is no place holder for VPN name. JNDI properties file will look something like this:
java.naming.factory.initial=com.solacesystems.jndi.SolJNDIInitialContextFactory
java.naming.provider.url=<IP:port><br>
Solace_JMS_VPN=<VPN Name><br>
java.naming.security.principal=<username><br>
java.naming.security.credentials=<password>
Here the jndi properties has to be packaged as a jar file and placed in the jmeter lib folder in order to be picked at runtime.
jar cvf my-jndi-properties.jar jndi.properties
Hope this helps.