In the Icenium Hybrid app we have a requirement like we need to keep the logged in user's session active for about 8 hours and then log-out automatically.
The app is connecting to the Servicestack REST services which also handles sessions at the server side.
How do we handle the session management on the device as well as server side?Any examples are highly appreciated.
Related
I am developing an hybrid mobile app that collects some user info in background while the user is calling (just during a phone call). Then I have an admin dashboard on a website, where the admins can monitor the (almost) real-time status of the mobile users. To do this, my mobile app must send info to the server. Right now I just use:
setInterval(sendData, 5000) to send data each 5sec from the mobile app to the server.
setInterval(refreshData, 5000) to request the current status from the admin dashboard to the server.
I don't need a "strong real-time", so it's enough update each 5secs.
Anyway I'd like to know if it's better use web sockets among the mobile app and the server, since the app should send data very often during the day.
Thank you
My understanding: In an Azure App Service, you can set the service to basically never "fall asleep" by setting the "Always On" setting in Azure Portal.
While this is an easy change to the service, I am trying to avoid having the service constantly run when not in use, and driving up the monthly expense of hosting the service.
My dilemma is that I have an Azure App Service running, which I authenticate a Xamarin Forms app against. In the process of logging in, I return an OAuth token to the client which is set to expire in 15 days (something long for testing).
Everything works fine while the Azure Service is running, but if the Azure Service "falls asleep" then I am forced to login again - which leads me to believe that the tokens issued by the service have been lost after the service falls asleep.
My question is: Is there a way to store the current tokens in an Azure Table Storage (or something) prior to "falling asleep", then pull from the same storage when the service "wakes up"??
I did find the below question, but couldn't get a clear understanding of how to persist the bearer tokens:
How are bearer tokens stored server-side in Web API 2?
I have been searching high and low with clear indication of how to do this, let alone if this is even possible.
Any help would greatly be appreciated.
The answer of How are bearer tokens stored server-side in Web API 2? you find is right. Usually, we will store the access token in client side. You can store it any place in your clients, local storage, sqlite, even files. Just to make sure, your application can get back the access token.
When your application send HTTP requests to the protected server, you will set the access token in Authorization header.
And your server once get a HTTP request, it will verify the token and authorize the user.
I have one Node Bluemix application configured with the SSO Service & connected with a Cloud Directory. I can successfully authenticate the user but I'm having problems to accomplish a successful logout. I have tried req.session.destroy, req.logout, and express-passport-logout module to end the session. But none of them worked. I also tried to remove cookies from my application but it didn't work as well. The only way it is working is by restarting the browser or clearing cookies from browser. Does anybody know how to achieve a SSO logout from the application?
The last time I used the service this was not possible. The problem is: what you are doing with the listed commands is to close your application session, not the one on SSO service. So when the user comes back (with the same cookie) your application will ask SSO service to check and it will accept the user (since the session there is still open). Currently there is no API available to close the session on the SSO service instance.
Actually, this becomes more complex when you use external IdP: even if you close the session at the SSO server, the browser will still have a session with the real IdP the user logged in from, which depending on the configuration of your service instance could be one or more of IBM, Facebook, Google, Linkedin. Some of these IdP's provide long-lived sessions via persistent cookies and your application can't force the termination on their side. That means that on next click of the "login" button, particularly in the case where the SSO service instance is configured to use only one IdP, SSO will happen seamlessly with no further interaction.
Take a look here to get more information.
As Umberto says, maybe it was not possible before, but now it seems to be:
Check this. You can redirect your user to this:
/idaas/mtfim/sps/idaas/logout
At least this seems to work if you only use Cloud Directory.
This may sound a silly question...
I want to authenticate an end user that connects to a webapi service against Azure AD.
The Web Server (where the webapi service is hosted) is located in a zone without internet connection due to security reasons, behind a reverse proxy.
The client (end user) is at home with internet (of course) and connects to the webApi service through the reverse proxy.
Does all/any of the available authentication methods against AZURE AD require that the server that hosts the webapi service has Internet connection?
Thanks
You can do this! :) As long as there is internet between the client and the identity provider (AD), you can always obtain a token and send it to the API - the API does not need a live connection to authenticate, it just needs to validate the token supplied by the client in the call.
The only tricky part is that today's OWIN middleware automates the acquisition of the token validation parameters by reading a discovery document hosted on Azure AD. That is clearly not an option in your case, but what you can do is to acquire that document out of band and use the info you find in there to initialize the middleware manually. Unfortunately we don't have samples that show how to do this, but let me see if I can get a snippet to post here.
I'm trying to design a green-field project that will have several services (serving data) and web-applications (serving HTML). I've read about microservices and they look like good fit.
The problem I still have is how to implement SSO. I want the user to authenticate once and have access to all the different services and applications.
I can think of several approaches:
Add Identity service and application. Any service that has protected resources will talk to the Identity service to make sure the credentials it has are valid. If they are not it will redirect the user for authentication.
Use a web-standard such as OpenID and have each service handle it own identities. This means the user will have to authorize individually each service/application but after that it will be SSO.
I'll be happy to hear other ideas. If a specific PaaS (such as Heroku) has a proprietary solution that would also be acceptable.
While implementing a microservice architecture at my previous job we decided the best approach was in alignment with #1, Add identity service and authorize service access through it. In our case this was done with tokens. If a request came with an authorization token then we could verify that token with the identity service if it was the first call in the user's session with the service. Once the token had been validated then it was saved in the session so subsequent calls in the user's session did not have to make the additional call. You can also create a scheduled job if tokens need to be refreshed in that session.
In this situation we were authenticating with an OAuth 2.0 endpoint and the token was added to the HTTP header for calls to our domain. All of the services were routed from that domain so we could get the token from the HTTP header. Since we were all part of the same application ecosystem, the initial OAuth 2.0 authorization would list the application services that the user would be giving permission to for their account.
An addition to this approach was that the identity service would provide the proxy client library which would be added to the HTTP request filter chain and handle the authorization process to the service. The service would be configured to consume the proxy client library from the identity service. Since we were using Dropwizard this proxy would become a Dropwizard Module bootstrapping the filter into the running service process. This allowed for updates to the identity service that also had a complimentary client side update to be easily consumed by dependent services as long as the interface did not change significantly.
Our deployment architecture was spread across AWS Virtual Private Cloud (VPC) and our own company's data centers. The OAuth 2.0 authentication service was located in the company's data center while all of our application services were deployed to AWS VPC.
I hope the approach we took is helpful to your decision. Let me know if you have any other questions.
Chris Sterling explained standard authentication practice above and it makes absolute sense. I just want to put another thought here for some practical reasons.
We implemented authentication services and multiple other micro services relying on auth server in order to authorize resources. At some point we ran in to performance issues due to too many round trips to authentication server, we also had scalability issues for auth server as number of micro services increased. We changed the architecture little bit to avoid too many round trips.
Auth server will be contacted only once with credentials and it will generate the token based on a private key. Corresponding public key will be installed in each client (micro service server) which will be able to validate the authentication key with out contacting auth server. Key contain time generated and a client utility installed in micro service will validity as well. Even though it was not standard implementation we have pretty good success with this model especially when all the micro services are internally hosted.