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.
Related
One Azure App service hosts a asp.net core API, another different Azure app service hosts a Web app. The web app can be accessed by end users that don't need to sign in (public). The web app calls the API. How can the API access can be restricted so that only the web app hosted in Azure can make calls to it, but end users cannot directly call the API end points, but the end users can still access the website (webapp)?
You asked a simple question that risks taking you down a rabbit hole. There are many ways to secure an API. The good ones require some thought.
On way is to involve a token server. The application and the token server share secrets. When application that wants to call an API, it is somehow redirected to the token server, and is granted a token. The session is redirected back at the API. The API checks with the token server that the token is authentic. If it is, the API serves the data, otherwise it fails.
This is an incredibly simplistic description of what really happens. Read everything in https://oauth.net/2/ for more details. Azure has mechanisms in the portal that can be used. https://identityserver4.readthedocs.io/en/latest/endpoints/token.html talks about how Identity Server could be used. There are other services of varying complexity and expense to do this. There are experts with varying rates that can help. I hope these couple links can get you started on your security journey.
you should be able to tweak the access restrictions of the app service to control the inbound access.
It allows to IP restrict/ Service tag based restrictions for an app service to accept traffic only from these entities.
I have created an azure signalr service with serverless option.
The negotiate function is able to generate JWT token with 'x-ms-client-principal-name' and the connection gets established without issues.
I have referred https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-concept-serverless-development-config and the function is able to send events to a particular userid/groups.
I have been asked to secure the client - server communication.
I am new to security domain. I referred https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-tutorial-authenticate-azure-functions this link but I am not able to configure the given sample app and not able to understand the concept.
My scenario is: I have a Client .net web app in which user can login using organization account as well as using google.
This app calls azure signlar negotiate function with userID and the deviceId in which it is interested to receive events through signalR function.
Signalr function gets events from the azure eventhub trigger and sends it to the groups.
Please help me to increase the security of this application. Is the token received from negotiate function sufficient as far as security is concerned?
Can any unauthorized user connect to my azure subscribeToGroup/sendEvent functions with the acquired jwt token from negotiate?
I am trying to use this https://github.com/Azure/azure-functions-signalrservice-extension in which idToken and claimTypeList are additional parameters along with x-ms-client-principal-name(userid). But I am not able to understand this with respect to security.
The client in this sample is index.html with auth.js. But how it is said to be secure is not understandable.
Please help and direct me for the correct setup and code.
I have a two slots for mobile app service at Azure: production and development. Also I have a client app that can work with this mobile service. Application version hosted at production slot does not contain authentication. Application version hosted at development slot has authentication and it works well. So, my client app can get authentication token and access protected API, and work with service hosted at development slot. When I swap this slots, client app still can get authentication token, but can't access protected API. I getting error 401 unauthorized on any attempt to call API using acquired token.
I'm using a custom authentication as described in docs
Both slots is identically configured: authentication: enabled, action to take when request is not authenticated: allow anonymous requests, authentication providers: disabled. As far as I can understand the one and only difference between those slots is URL. It looks like when the url of service is changed, it starts to generate invalid tokens.
That can be a cause of this behaviour?
For anyone else coming across this question, there are a few additional things to consider when using Azure authentication and slot swap. First, the Azure team has corrected the hostname issue, so all slots have the same hostname (you can verify this in the Environment settings for each slot). Tokens generated on one slot are now completely valid on all other slots.
HOWEVER, when a token is generated, it is stored in a folder on the hard drive of each slot, and that folder is not sticky to a specific slot. This means that if you have client users using a token for your production slot and you swap production and staging slots, that client's token WON'T be valid anymore (because their token reference that was on the production slot is now on the staging slot).
This may or may not be an issue for your app. If you require users to log in frequently, then they may not even notice the extra need to login. If however you have long lasting tokens (like most social networking sites) then this can cause some headaches.
One of the parameters that involved in token creation process is hostname. In my code hostname value was provided from MobileAppSettings. The problem was that MobileAppSettings return the hostname value of development slot after the slots swap, so the generated token is invalid. Service restart fixes this behaviour.
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.