What would be the best way to implement single sign on for a group of web applications developed using different back end stacks without using any third part services and without taking them down. How can be the migration be done ?
For single sign on to work, you must have same database table which contains username/password for all the web applications
Create and deploy a web service which has login method with two parameters username and password. This method authenticates user and returns user id and their respective role and login valid upto time.
if user is authenticated FIRST TIME, update valid upto time for that user into
database for which user will remain authenticated. e.g. 10 days from
now
If authentication fails, login method should return false
In each web applications, in webservice callable method, if user login is succeed, create a cookie which should be expired on validupto
time return by web service. Adjust cookie time as per server's timezone
let's guess, user is validated from web application1 and cookie is created which is not going to expired for the next 10 days as per
validupto time
Same user opens web application 2 who is not logged into web appliation2. Here you have to check whether login cookie is found or not, if not call webservice,
webservice will check that user's validupto is more than current time
from db so it will return user id and his respective role, validupto time directly without checking user's credentials
So here again, cookie will be created based on validupto time returns by webservice which will
expire on the same time as web application 1 cookie. So the same user will remain logged into both web application 1 & 2 for the same time.
Once cookie is expired, user will be logged out from both web applications.
This way, you can use as many web applications as you want for Single Sign On.
NOTE: Make sure that you have same fuction in all web application which calls webservices and creates cookie based on web service response.
Related
There is any webservice providing by WSO2 Identity server, to remove a session for specific user to specific ServiceProvider?
I am using SAMLSSO for many web application and they all are integrating with WSO2 server.
Now let's say scenario is,User is login with 2 application at the same time. I want to logout it from one application.
There is one service provided by logout and it's providing single logout and session will be remove for all application. There is webservice provided by IS or way to achieve logout for one specific application ?
What you are asking is to have the capability of removing a specific participant from the session created in the Identity Server side. I don't see a straight forward way (OOTB) of achieving this.
Closest you can achieve is as below.
Make your application perform a forceAuth. ForceAuth will request for user credentials despite having the cookies in the browser. (This will prevent the user from experiencing the SSO comfort. Still you can authenticate against the IS)
Prevent the application from sending an SLO request to WSO2. Rather, terminate the self(application) session upon logout.
When your application really wants to perform an SLO (logout all the applications, not just yours), your application can send an SLO request to the Identity Server.
Performing a force authentication :
SAML - Send forceAuth=true as a query paramter in your login request. Or else change the SAML AuthenricationRequest payload body to indicate a force authentication as in the spec(Line 2042).
OIDC - Send prompt=login as an additional query parameter in the /authorization request.
You can do this by calling the REST API and SOAP API provided by WSO2 IS. This will remove the session at WSO2 IS but I'm not sure if it will also trigger the SLO to other service providers or not.
Reference:
https://is.docs.wso2.com/en/latest/develop/calling-admin-services/
https://is.docs.wso2.com/en/latest/develop/session-mgt-rest-api/
Trigger a SOAP request getUserProfile from the UserProfileMgtService.wsdl. The default user profile will be 'default' or you can put the customized profile name you used. This will return the details. Grab the user id from this.
Trigger a GET to the API: /{user-id}/sessions with the user-id from step 1 to get the list of all active sessions this user currently have. Go through the list of sessions and find the session ID of the Service Provider you need to clear.
Trigger a DELETE request to API: /{user-id}/sessions/{session-id} with the user id from step 1 & session id from step 2
I am trying to build Blazor server side app using cookie authentication without ASP.NET Core Identity. I did manage to get authentication following sample above.
In my app I skipped services.AddIdentity and app working so far without problems, I am able to login, logout, determine user roles and others.
What I am not quite sure that I understand is RevalidatingServerAuthenticationStateProvider class and its service, services.AddScoped<AuthenticationStateProvider, RevalidatingIdentityAuthenticationStateProvider<AppUser>>();
Does Blazor app need this service to continue communicating with client, or it is just security barrier?
I am ok to client remains logged in as long as cookie is not expire.
If I need RevalidatingServerAuthenticationStateProvider service how I can confirm that user is valid from passed AuthenticationState? (looking in claim or something else).
here,
protected override TimeSpan RevalidationInterval => TimeSpan.FromMinutes(30);
means, in every 30 minutes, this mechanism will call ValidateAuthenticationStateAsync to check whether current auth is valid or not.
I'm setting up a Django-React application, with authentication through third party CAS. The process of CAS authentication looks like following:
The web application redirects the user's browser to CAS's login URL with a "service" parameter, for instance https://cas.com/login?service=http://myapp.com.
Once the user has been authenticated by CAS, CAS redirects the authenticated user back to the application, and it will append a parameter named "ticket" to the redirected URL. Its ticket value is the one-time identification of a "service ticket". For instance, http://myapp.com/?ticket=abcdefg.
The application can then connect to the CAS "serviceValidate" endpoint to validate the one-time service ticket. For instance, https://cas.com/serviceValidate?service=http://myapp.com&ticket=abcdefg.
In response, CAS shall return an XML containing the authenticated user id, for instance,
<cas:serviceResponse>
<cas:authenticationSuccess>
<cas:user>johnd</cas:user>
</cas:authenticationSuccess>
</cas:serviceResponse>
I've done some research and found it could be implemented in mainly two ways:
Serve react as part of Django's static content.
Standalone react single page application(SPA) through JWT.
I've tried the first approach and it works, but the problem is that every time I want to test the authentication with React, I need to build the static file first and put them in Django, which is kind of slow. So I would like to try the second approach.
My question is that is there any best practice I could implement for the standalone approach? If I were to implement JWT, is it safe to store the access token in localStorage or cookie?
Many Thanks!
I have set up Django OAuth Toolkit in my project where the authorization server is separate from the application server (i.e accounts.example.com and app.example.com). App server redirects to accounts server using authorize flow; the user inputs credentials to sign in to auth server, then auth server redirects the user back to application; so that the app can retrieve tokens.
The above flow currently works as expected. If I do not click explicitly Log out the user and the application signs out (e.g session expires or browser cookies are cleared), the above flow will be performed again and there won't be a need for credentials because auth server still knows who is signed it.
However, I am having trouble with explicitly logging the user out of the application. If a user explicitly clicks login, firstly, the token must be revoked and secondly, the auth server must sign out. What is the proper way to achieve this? As far as I am concerned, I won't be able to use Ajax to log out the user because the session must be destroyed in auth server.
So, I have been thinking of redirecting the user to accounts.example.com/signout?token=${accessToken}&client_id=${clientID}. However, I am not sure if this is the right approach. Is this how these sign out requests work with OAuth? Does that mean that when I sign out from the system, I need to always provide Access Token and Client ID?
I am developing hybrid mobile Application using phonegap(jquery mobile framework) and jersey rest java webservice.
How to do login and logout using mysql and rest webservice and maintain session of perticular user on every page like traditional webapplication(get username on every page).
i am totally stuck.can anyone provide sample example or any solution.
you can do in below way.
create session table contains column [id, token, userid, loggedintime]
on login call a rest like /rest/user/login?username=uname&password=pwd
which return a token to user. maintain that token at client side. you may use cookie or sessionstorage whichever supported by mobile device.
now create one Filter with path /* so each request pass through it, and in filter check that the users token is valid or not, if not than redirect to login. you can explicitly pass that token to server in queryparam or pathparam.
on logout delete entry from session table, and redirect user to login page again.
there are many way to do this thing but this is a simpler way.
It's simple, you store the username and password in your client and send them with every request. (On the server side you can have an (username, password) -> (identity, permissions) in-memory cache which can make things faster.) You need a secure connection: HTTPS. Without that you won't do REST auth.
Login is simple you show a prompt to the user, in which she can give the username and password, so you can store them in the memory of the client. By logout you can simply close the client (by browsers navigate away), or remove the username and password from the memory of it. (It is not secure to permanently store the username and password without proper encryption on the client side.)