This is what I want to happen.
Current Setup: Two wars deployed in Websphere v8 (App1 and App2). Both have a login feature where users enter username and password to get in the app. This is not using LDAP or JAAS, its just plain query from the db to check if username and password is correct.
Problem: There had been a move to "combine" the two apps where authenticated users in App1 can now access App2 directly without logging in and having the same session. If user accesses a module in App2 without logging, user will be directed to login page of App1 to login.
Other factors:
App1 and App2 are in the same websphere instance in the same box and in the same cell.
Question:
Is it possible to implement SSO and shared session between App1 and App2 in websphere?
From what I read you are either performing the authentication on your own with App1 and App2, meaning without using WebSphere Security or you have both applications inside two different WebSphere Cells where no SSO is setup.
If it is option 1 I strongly recommend you to take a look at WebSphere Security and what the container provides you there.
Which brings me to option two cells without SSO
WebSphere Application server builds out by default a Cell wide SSO model. A cell means a collection of servers which are controlled together. By default WebSphere uses a token named LTPA_Token or since 6.1 LTPA_Token2. At the cell level the security is configuired which includes the SSO domain, which is in fact "just" the cookie domain. WebSphere persists the authentication state inside of the token as a cookie and the browser will submit this to the server matching to the cookie domain.
Having said that. If you have two cells you can exchange the security keys between these two and so they can both understand the security Token created by both of them. You need to ensure some additional information like realm, security domain, attached user repository.
As you mentioned App2 should send all users to App1 you probably need to define the End point to handle the Authentication within your web.xml and have it point direct to App2 or write a TAI (Trust Association Interceptor) on App2 to send all not authenticated requests to App1
In addition you could as well put an authentication proxy in front of the two applications which will only ensure the authentication state and establish the security state as the request is passed to the backend.
For reference
WebSphere Application Server Infocenter Topic
Related
We are considering using Keycloak for our public REST APIs (mostly Spring boot apps) to authorize and authenticate our users.
In order not to make the admin UI publicly available we want to restrict it.
Our idea is to create two instances but access the same database.
the public Keycloak instance, which only publishes what is necessary e.g. the admin path is not accessible. In this instance only paths should be accessible like these recommended here: https://www.keycloak.org/server/reverseproxy#_exposed_path_recommendations.
a private Keycloak instance, which is only accessible from the internal network, but offers the admin UI (console). With which one can then manage the users/permissions.
Is this a valid solution to have two different instances but with the same database or are there other best practices here to not publish the admin ui/paths?
Yes, this is definitely a common setup. Depending on your requirements, it is always recommended to have more than one instance of Keycloak on the same database, for availability reasons. Keycloak shares some in memory data (like sessions) in an Infinispan Cache, which is shared between one or more instances of Keycloak (generally referred to as a cluster)
You would then use a load balancer (like haproxy, nginx, apache, the choices are practically endless) and configure it to send requests to the actual Keycloak instances.
A possible setup could be the following: Using 4 Keycloak instances on 4 servers:
public-keycloak-1.internal.example.com
public-keycloak-2.internal.example.com
private-keycloak-1.internal.example.com
private-keycloak-2.internal.example.com
You can then add 2 load balancers:
keycloak.example.com (sending requests to public-keycloak-*)
keycloak.internal.example.com (sending requests to private-keycloak-*)
In this example, keycloak.internal.example.com would be the instance you connect to, in order to perform administrative tasks in Keycloak via the Admin Console, or the Admin API, and keycloak.example.com would be the host that you use for Auth{n,z} for your applications.
Restricting access to the Admin API and Admin Console can be done at the load balancer level (restricting requests to those paths), but since Keycloak 20, it is also possible to completely disable the Admin API and Admin console. This is done through the disabling the respective features seen in the documentation. That way, you can disable the features "admin-api", "admin" and "admin2". If you do this on the public-keycloak-* instances, then requests to the public load balancer can never end up touching the Admin API or Console, because Keycloak is configured to simply not serve those requests in the first place.
I have a request to restrict the access (access control) to a small user community in GCP.
Let me explain the question.
This is the current set up:
A valid GCP Organization: MyOrganization.com (under which the GCP project is deployed / provisioned)
Cloud DNS (To configure domain names, A & TXT records, zones and subdomains to build the URL for the application).
Oauth client set up (tokens, authorized redirects URIs, etc.).
HTTPS load balancer (GKE -managed k8s service- with ingress service), SSL certificate and keys issued by a trusted CA.
The application was built using python + Django framework.
I have already deployed the application (GCP resources) and it is working smooth.
The thing is that, since we are working in GCP, all IAM users who has a valid userID#MyOrgnization.com can access the application (https://URL-for-my-Appl.com).
Now, I have a new request, which consists in restricting access (access control) to the application only for a small user community within that GCP organization.
For example, I need to ensure that only specific IAM users can access the application (https://URL-for-my-Appl.com), such as:
user1#MyOrganization.com
user2#MyOrganization.com
user3#MyOrganization.com
user4#MyOrganization.com
How could I do that, taking into account the info I sent earlier ?
thanks!
You can use Cloud IAP (Identity Aware Proxy) in order to do that.
Identity-Aware Proxy (IAP) lets you manage access to applications
running in App Engine standard environment, App Engine flexible
environment, Compute Engine, and GKE. IAP establishes a central
authorization layer for applications accessed by HTTPS, so you can
adopt an application-level access control model instead of using
network-level firewalls. When you turn on IAP, you must also use
signed headers or the App Engine standard environment Users API to
secure your app.
Note: you can configure it on your load balancer.
It's not clear in your question if your application uses google auth (but considering that you talk about org-restricted login I think so) - if that's the case you should be able to enable it without virtually touching anything in your application if you are using the Users API.
The best and easiest solution is to deploy IAP (Identity Aware Proxy) on your HTTPS Loadbalancer
Then, grant only the user that you want (or create a gsuite user group and grant it, it's often easier to manage)
I am currently building a microservices based application in spring boot with the following services
Auth server (Distributes access tokens)
User service (User info like username, password, email, etc.)
Various other unrelated services
When a user sends their credentials to the auth server, the auth server should verify that they are correct and then return an access token.
My question is, should I combine the auth server with the user service so looking up credentials is a simple database call, or should I keep them as separate applications and have them both point to the same shared database? Is there a better alternative?
What I usually do is keep them separate. Account information (first name, last name, contact data, affiliation, sex etc) is not related to authentication/authorization. Also, an account can have multiple authentication methods (i.e. OAuth, uname-pass, private key), which isn't really related to account data. So, I take them as separate entities. I know auth and account data seem the same, but they represent two very different things, with very different responsibilities, so I keep them separate. If one user should have to see some other user's first and last name, I wouldn't like to get other user's credentials out of the database (a lot can go wrong).
If you are thinking of UserService from Spring Security, it goes with Auth server.
From security stand point, having a single point of truth (auth server) and be able to fix an issue in one place is a huge advantage.
Anyhow, IMHO, account and auth can share some properties, but they are two different things - hence I keep them separate.
Hope this helps.
You should keep them separated, oauth is not related to identity management but to authorization delegation.
In oauth2 there are 4 roles (resource server, resource owner, client and authorization server) you are currently asking if the authorization server must be part of one microservice of the resource server which has absolutely no sense.
If I correctly got your case what you name a user corresponds to the resource owner role in oauth2 terminology, some oauth2 flows (e.g. client_credentials) directly allow a client to get an access to the resource server and there will be no users implied in any way.
Why sharing session to implement SSO is not good? I'm learning SSO system.
Thinking about this scenes:
Assume that all http requests to business services is required Login, the business services need verify the requests is login or not by asking SSO service in CAS or SAML. If there are 10 business services, and each service's request is 1k req/s, so the SSO service's request is 10k req/s. It's hard to image the SSO service can hold on.
SO, may be there is a cache mechanism in the business services to verify login token. But when user logout, the SSO service need remove the verify info, and the business services need remove the cache verify info also. I think that's too complicated. The SSO service need tell the business services some people was logout. So why don't all service sharing the login token verify info? Let SSO service write, and other business read. It remind me the sharing the session to implement SSO. And I thought if I can sharing the login token verify info by redis distributed cluster. But I have hear sharing session is not good? So why?
Whether the SSO server can handle that many requests depends on your deployment of it. There are very large deployments of CAS that handle hundreds of thousands of requests. It varies.
In general, the SSO session is entirely separate from your application session. Once you have logged onto the application via SSO, you have established a session for that application that will last for as long as you configure it to last. When it expires, your application may decide to authenticate against your SSO server again. If the SSO server has still an SSO session, it will simply re-issue the appropriate data and your app will recreate the session. If not, it will challenge the user for credentials, whatever they may, and redo the same.
Session concerns of the application are entirely yours and application's concerns. The SSO server should never get involved. If your application has a requirement to share sessions because it's clustered, then you should share sessions. Nobody said it's a bad idea. However, you generally want to make sure your application is as stateless as possible since that will make clustered deployments easier.
When you log out from your application, your app session is gone, but the SSO session may still exist. As a result, you will get right back into the app because there is no need to provide credentials. If you wish, you could log out of the app AND your SSO server.
If you have all other applications logged in via SSO, and you wish to log out of all by logging out of one, this is called SLO. Your SSO server will need to reach out to every app that it has created a ticket for and contact them to logout. Or, you could destroy the shared sessions for all apps assuming they are all part of the same suite.
I have an online and a mobile application. Is it possible to do some setting in Websphere application server, so a customer can login in only application at a time. IF already logged from online, and tries to login from mobile, then he should be logged off from Online. Two applications are different, and no connection between them. But for authentication they call a single service, which is inside a separate EAR, and exposes suthentication service as webservice.