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
Related
I've written a software system that uses Spring Cloud Netflix. Due to Spring Security 5 not offering support for writing an Authorization Server (pls shout out here https://github.com/spring-projects/spring-security/issues/6320) I need to write my own Authorization server. I want my application to permit Social login and username/password registration, have a custom login page but also use keycloack. I don't even know from where to start, if you have any documentations or code samples please provide.
You can use the cas project. By using the overlay it is easy to set up and to customize:
https://github.com/apereo/cas-overlay-template/blob/master/README.md
It serves a frontend where your user can be redirected to and can login. After successful login, the user is redirected back to your web page. The frontend is completely customizable.
It supports all kinda of authentication providers like keycloak, database or Google/Facebook.
After basic setup you just add the dependency inside the gradle file, configure your keycloak/database/... in the application.properties and can start using it as authentication server.
It fits perfect into a microservice landscape and is curated by professionals implementing security best practice.
https://apereo.github.io/cas/6.1.x/planning/Getting-Started.html
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.
I'm trying to set up a sample application using spring boot admin (both server + client side) and have run into an issue with authentication.
When spring security is enabled on the management/actuator endpoints on the client side the spring-boot-admin server does not seem able to communicate with the client -- logging in to the Admin interface via a Web browser results in a continuous loop of authentication windows popping up and prompting for usernames/passwords. Hitting cancel will display an HTTP 401 error on the page.
Here's a configuration that works on the client side:
management.security.enabled=false
security.basic.enabled=true
security.user.name=test
security.user.password=test
spring.boot.admin.url=http://localhost:9081/admin
spring.boot.admin.username=admin
spring.boot.admin.password=admin
This will:
Disable security for spring-boot's management/actuator resource
Enable security for all other resources (HTTP basic auth - user: test, password: test)
Register the spring-admin client on startup using the url http://localhost:9081/admin (HTTP basic auth - user: admin, password:admin)
I'm guessing the spring boot admin app doesn't support communication with secured clients because I don't see any configuration properties that would allow the information to be passed in upon client registration.
Has anyone got around this limitation and if so, how? I'd rather not leave the actuator endpoints "open to the public" so-to-speak, even though they are actually just exposed on the company's internal network.
There is no security feature included since the various solutions look very different. But I've put up some examples: https://github.com/joshiste/spring-boot-admin-samples
I have been trying to use the CAS Authentication for a Websphere Portal 8.0.1 application. Followed a few links :
https://wiki.jasig.org/pages/viewpage.action?pageId=19314
https://portalplus.wordpress.com/2012/04/10/configure-websphere-portal-with-cas-sso/
This help was mainly in pursuit of finding a ready-made Trust Association Interceptor (TAI) and a possible login modules if needed.
But looks like Portal CASsification is not a well known territory. I did all the configurations , but looks like TAI is not calling CAS serviceValidation URL, so even when I am redirected to portal application , the session is not authenticated, So I see blank portlets.
So I am stuck at a few points :
Apart from Yale provided TAI , is there a open/closed sourced library for CASifying Websphere portal application.
Do we need to provide CAS filters in wps.ear web.xml or in the web.xml for the portal application war.? Or should be taken care by the TAI interceptor ?
Websphere portal is very rigid to the open source auth libraries!!
Appreciate any help!!
What's the best way to configure SSO between a WebSphere Portal Portlet and a .NET application?
We are using WebSphere Portal 6.1.5 and the portlet should just redirect to the .NET application, but not require the user to login since they already did on portal. Both Portal and .NET app are using same Active Directory(LDAP) for authentication.
SPNEGO is a mechanism that is widely used in WebSphere and Windows for SSO. I am not sure about .Net applications but it is worth your time to explore and see if this would help you in achieving your needs.
Try this for some basic info on SPNEGO and WebSphere
http://www.ibm.com/developerworks/websphere/library/techarticles/0809_lansche/0809_lansche.html
Using same LDAP for authentication does not necessarily mean anything. In most of the SSO scenarios, not all the back end servers use the same LDAP repository. All i am trying to say here is that there is no strong co-relation between the LDAP server and SSO.
HTH
Manglu