I am switching from Websphere 8.5.5.0 to 8.5.5.9. I have two questions on the datasource configuratioin.
Do I have to use JAAS in liberty or the <properties.oracle
user="xxx" password="yyy" URL=zzz/>is sufficient?
Is there a test datasource button in the Liberty adminCenter like
it's in the traditional admin console?
You don't have to use JAAS for your datasource authentication with Liberty, but if you use userid and password properties, you should at least use the tools to encrypt them to provide a minimal level of security.
Liberty Admin Center doesn't yet have a "Test Connection" button like traditional Admin Console, but you can RESTfully test a datasource using the new function described in this wasdev blog.
Related
In Websphere admin console, it provides the ability to use Standalone LDAP registry as a method to authenticate user to login to the admin console.
Security > Secure administration, applications, and infrastructure > Standalone LDAP registry
And then enable Enable administrative security checkbox in the admin security section.
Is there a way to leverage this LDAP connection from application point of view? e.g. The J2EE application runs on top of the Websphere also uses the LDAP connection to do application user authentication. Currently the application have classes like import javax.naming.ldap.LdapContext, and create a separate LDAP connection context to authenticate the user at application level. Is it possible to use the same connection make in the admin console, or is it totally impossible?
I searched the redbook WAS8 Administration and Configuration Guide.pdf www.redbooks.ibm.com/redbooks/pdfs/sg247971.pdf and didn't find anything.
and also checked http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.base.doc%2Finfo%2Faes%2Fae%2Ftsec_ldap.html didn't find anthing.
I am using Websphere 8
You can enable the Application Security from the Console in order to use the Websphere(i.e. Java EE) security scheme.
You can do this by checking the "Enable application security" checkbox in Global Security page of WAS Console and make the appropriate changes in your app. For more look in the following Redbook for Application security.
However you should know that you might need to adapt your application to Java EE Security Standards, which might be difficult.
I am considering integrating IBM's Tivoli Access Manager with Jenkins for user authentication. TAM uses something called a WebSeal to allow users to login and then forwards the creds for that user in the HTTP header to the desired service. I am new to Jenkins and was wondering what would be the easiest approach to do this. I noticed that the existing OpenId plugin extends the FederatedLoginService currently present in Jenkins. Could something similar be done to integrate TAM? If not, where would I extend Jenkins to allow the extraction of the creds form the header provided by WebSeal?
Thanks in advance.
To make #daniel-beck’s suggestion into a concrete answer: the Reverse Proxy Auth plugin is the way this sort of integration is normally done in the absence of a dedicated SSO plugin, though I do not know specifically whether WebSEAL sends headers suitable for consumption by this plugin. From what I can glean by searching, you would get HTTP_IV_USER and HTTP_IV_GROUPS.
I'm able to protect Worklight console with an user inside worklight.properties file (on Liberty or WAS environment).
How can I protect console with a LDAP user (outside of the worklight.properties file)?
Yes, you can do this.
You will need to edit your authenticationConfig.xml as follows:
Add a LDAP loginModule
Add a LDAP realm
Update the existing "WorklightConsole" custom securityTest to use the new realm
After the above changes, once loading Worklight Console and entering the user credentials,
these should be handled by the loginModule to authenticate against the LDAP server.
See the following IBM Worklight Getting Started training module, which is about this very topic:
Using LDAP Login Module to authenticate users with LDAP server
I'm involved in an Java Web Application Migration project to IBM Websphere Portal (IBM WP) Platform.
The actual application in production environment validates manually user credentials (username and password) against a Database Table that stores the data. I understand that the idea behind a Portal application is that the Portal Container handles this Security issues, but I'm not sure how IBM WP can consume the credentials that now are on Database.
There's a brand new Tivoli Directory Server in the Company, and I'm aware that I can't connect IBM WP to this LDAP Server so, do I need to migrate every user in the Database to this LDAP Server, or there's a Way that Tivoli recognize the credentials that are on the database?
Trust Association Interceptor are powerful, but they totally override Websphere Authentication mechanisms, so be sure to write a quite robust one! As Carlos Gavidia suggested, I'd also give a look to Custom User Registry. I'd also suggest to consider Property Extenstion Repository (also know as Lookaside), so you can define your own attributes and read/write them directly from Portal API
http://www-01.ibm.com/support/docview.wss?uid=swg21248674
You can hook in any kind of custom authentication you need using a Trust Association Interceptor. Your custom authenticator would probably work a lot like the authentication code in your existing system. It would display a page prompting the user for their credentials, and then check them against the DB.
I'm not sure how this relates to your Tivoli LDAP, but there seems to be a provided TAI for TAM integration: Tivoli Access Manager Trust Association Interceptor (TAI++)
this is my first time trying spring security and ldap. I have couple of novice questions. My main confusions are:
How do we assign roles to users? Is it done on ldap server? or done via a configuration file in my webapp? By roles I mean, Couple of users would have all the access to webapp features(Admins), Regular users (Read only access to webapp data), Analytic group (Users which can run a report in webapp)
Currently application uses j_security_check for normal user authentication with ldap server. (Where is Websphere do we hook up ldap connection settings for this authentication?)
I found it confusing too, and developed my own module which ties in with Java EE Security.
Basically the webapp is set up with standard Java EE Security, and methods on spring beans can be given the #RolesAllowed annotation, in which case the logged in user's roles are checked against the required roles just before calling the method. See here for details.
You can use LDAP or a database or a file - where the roles and users are stored is up to you. Normally for production, you will use LDAP or a connector to some kind of directory server. Sorry I can't help with WebSphere - been a while since I set it up for security.