I am using WebSphere v8.5 and in the administration console, and the Security Settings in the Data Sources section allow me to set my mapping-configuration alias to either ClientContainer or WSLogin. What is the difference between these two settings?
I am able to connect and my project appears to work regardless of which setting I choose. Can someone please explain when is one setting chosen over the other?
Each one in the list is a Java Authentication and Authorization Service (JAAS) configuration, which in turn contains an IBM-implementation of the JAAS Login Module.
According to the reference page, Login configuration for Java Authentication and Authorization Service:
The WSLogin module defines a login configuration and the LoginModule implementation that can be used by applications in general.
The ClientContainer module defines a login configuration and the LoginModule implementation that is similar to the WSLogin module, but enforces the requirements of the WebSphere Application Server client container.
The DefaultPrincipalMapping module defines a special LoginModule that is typically used by Java 2 Connector to map an authenticated WebSphere Application Server user identity to a set of user authentication data (user ID and password) for the specified back-end enterprise information system (EIS).
So for general use, you can use the WSLogin module. When you use a Java EE client, use the ClientContainer module. And when using Java 2 Connectors, use the DefaultPrincipalMapping module.
Check this link for a bit more information Configuration entry settings for Java Authentication and Authorization Service
In general, for any server resources like Datasources, queue connection factories etc, you should use DefaultPrincipalMapping.
ClientContainer alias is more dedicated to external applications running in the client container that will connect to WAS, and WSLogin is more appropriate for apps running on the server that would like to customize authentication process.
Related
I am working on a Spring boot application and have received a requirement where a certain endpoint must be accessible only by authorized users that too the user must be present physically at the system serving the app. An optional case is the user could also be able to access the endpoint if the user has SSH access to the server. This makes me think that some sort of key (a file or a program) can be used to unlock the endpoint. Not being a person proficient in security, this has put me at a loss on how to implement such a feature using Spring Boot. Any help is appreciated.
Spring boot doesn't have built in support for this scenario, but what you actually need is PAM (Linux Pluggable Authentication Modules) port for java (JPam can be a good solution).
You can write your own AuthenticationProvider for spring security which will do something like this in it's validation method:
Pam pam = new Pam();
boolean authenticated = pam.authenticateSuccessful(username, password));
This library is good enough documented (pdf)
Another PAM for java solution can be found here libpam4j
We are currently developing an application for a customer. The project has the restriction that we shall deliver only deployable WAR files. The customer provides the infrastructure and doesn't allow much deviation from it.
The application is developped with Spring Boot, Spring Security and SAML. The current version is a single monolithic WAR file.
At the moment, we are in the process of splitting this monolithic application in separate applications because of multiple reasons (maintainability, deployment, code quality, ...). Unfortunately we do not know yet how to implement authorization with these given restrictions:
Infrastructure constraints:
Applications will be deployed on JBoss EAP 7.0
A custom Identity Provider is provided by the customer
Communication with IdP has to be implemented with SAML 2.0
The custom IdP has the following restrictions:
Authentication is done through a proxy, which means only authenticated users arrive at the application
Only one SP metadata file can be provided, because it is linked to the user database. We want to share the same user database for all applications.
The SP metadata file can only provide one AssertionConsumerService-Location
The AssertionConsumerService-Location is statically defined in the metadata file and cannot be overriden in an AuthnRequest
Problem description:
Each application has to authorize itself with the IdP to receive roles and assertions. With the current (monolithic) deployment this is no problem as we require only a single AssertionConsumerService. With the new architecture, each application is able to redirect to the IdP, but the IdP can only redirect to the statically configured ACS. How can each application receive the AuthnResponse, when only a single ACS is possible?
Any ideas?
From SAML-standards point of view this could be achieved with an SAML IdP Proxy. Your apps, acting as the ServiceProviders only communicate with the IdP part of the IdP Proxy. The actual IdP only communiates with the SP apart of the IdP Proxy (so there is only a single ACS url).
How do I set the fallback page for websphere 6.1 and websphere 8.0?
When I could not load the SPENGO login, I want to have a fallback page to show the simple form login page? Is this possible? Is so, how do I set it up for websphere 6.1 and 8.0?
Unfortunately it is done very differently.
In WebSphere Application Server v6.1 SPNEGO is implemented by the TAI (Trust Association Iterceptor). There is no automatic fallback to default login mechanism, however you can do it by yourself. There are two properties - spnegoNotSupportedPage and NTLMTokenReceivedPage - where you can provide custom pages, which would allow users to access application and bypass SPNEGO challenge e.g. by addinin &noSPNEGO to URL.
For more detailed description of these properties look here - SPNEGO TAI custom properties configuration
In WebSphere Application Server v7 and later SPNEGO is implemented by the web authenticator. It is not configured via TAI properties, but via Global Security > SPNEGO web authentication, there you have option Allow fall back to application authentication mechanism, which will kick in if SPNEGO login fails.
In some cases, default fall back may not work and you will need to define similar properties like in v6.1, but this time via SPNEGO web authentication filter.
For more details look here:
SPNEGO web authentication enablement
SPNEGO web authentication filter
we are providing facility to customer to configure ldap server runtime. But when i modify provider server url used in constructor of context source, the application crashes. Is there any way to change ldap server url at runtime? for LdapAuthenticationProvider.
If this is a case where you are changing the provider because one may be down for some reason, you should set up multiple authentication providers (security:authentication-provider) in your spring-security config file. Spring-security will start at the top of the list & keep trying until it finds one that works. That way you can leave this setup & not have a need to redeploy your code.
I have Websphere Application Server version 7.0, running on Windows.
I created a JAAS Login Module that implements the javax.security.auth.spi.LoginModule interface and created a data source that uses this login module (under Mapping-Configuration alias). Since this data source should get the credentials for the connection from the login module, there are no authentication alias configured on the data source.
I want to use this data source on my application, but my application uses direct JNDI lookup for the data source. According to this article, when using direct JNDI lookup, websphere creates a default resource-reference that is configured with res-auth=application. Since the res-auth is application my login module is never invoked, but I get a logon denied error because the "Component-Managed Authentication Alias" is empty.
I tried to create a resource reference manually with res-auth=Container but it didn't help.
Is there any way to change the default res-auth to be Container?
Is there any way to make a login module work when the res-auth is set to Application?
Thanks.
Go to your datasource >> security settings >> select your jaas login module for both Component-managed authentication alias & Container-managed authentication alias
Regards,
u can change res-auth in web.xml file to container, so it will use container managed authenication alias.