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.
Related
I have a vps, where my spring boot backend is running on. The frontend is a mobile app built with the ionic framework.
The backend is built this way: in the front there is an so called resource server, which is an graphql server, which redirects the requests to rest microservices which are behind the resource server. Every microservice has is own task, which he's responsible for. (e.g. an fileupload-server which uploads/downloads files to a database). The whole application, including the frontend is secured by an keycloak instance, which is running as an docker container like the whole application, except the frontend.
Now my questions is, we dont have a domain and for some reason they wont buy one, but we wont to secure the communications over ssl/lets encrypt. But lets encrypt isn't able to create ssl certificates for ip adresses. So finnaly my question is: do you guys, know a solution to my problem which fits?
So far,
Daniel
I have written a web application that is, typically, installed internally by customers (based on IIS/MSSQL server).
When a customer wants to provide external access to the application, we offer the following supported scenarios:
Publish the application in their DMZ (pretty standard deployment).
Use our own platform where we host the application in our own cloud infrastructure for them.
However, because I have more and more customers who misunderstand the requirements for publishing an internal application, I would like to add a "one click" way of providing that service.
My idea is to have a reverse proxy installed on the customer's web server that will connect to a cloud server we control. When the application starts, it will connect to our server, authenticate and maintain the connection. When a user wants to use the application, she will use an URL that directs it to our server (say https://myapp.mycompany.org/CustomerID or https://CustomerID.myapp.mycompany.org). The server will then lookup the list of connections from reverse proxy to find the one matching the customer ID and, if found, use that connection to relay the end user connection.
In essence, that is the same thing as what Azure Application proxy or TeamViewer do, only without the need for using Azure AD or TeamViewer.
Is there an existing framework I can use for building such a service ? I know I can write it on my own but that is quite a large development.
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.
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
I'm in the process of rearranging our web-based systems, so that users will be able to log on to our systems through a Sharepoint front-end. Our single sign-on server is an Oracle SSO server that authenticates against the same domain as the sharepoint server does, but these two are currently 2 separate logins.
What I'm looking for is to configure this scenario:
A user logs in to the Sharepoint site, authenticating agains Active Directory through the TMG. This gives the user access to the sharepoint site, and this is all standard OOTB functionality. Then the user should be able to navigate into our other systems without a re-login (because the SSO configured for external authentication with the same AD, and therefore uses the same userbase).
So basically the users currently have to login twice with the same domain\user + password. I would like the SSO server to be able to read the cookie that was established in the first login, and use that instead of presenting the SSO login screen all over again.
Is it possible to share such a cookie between 2 different platforms on the same domain?
I have implemented a kerberos "Zero-sign-on" approach for the Oracle SSO server, but this only works as long as the user comes from a computer inside our domain. When the user logs on from the outside world (www) he will be prompted to login to sharepoint first, and then to the Oracle SSO.
I basically need the Oracle SSO Cookie to somehow read the Sharepoint Cookie that was established. Does this make sense?