I am making an application to be used as a service by telephones over GSM network.
The app will be running in a web server and will be connected by web service to GSM application.
Specifically, the service will use USSD mobile protocol to talk to end user phones and I need a way to authenticate and persist user sessions so that ussd requests in the same sessions only authenticate once.
One solution is to use the built-in sim PUK mechanism to authenticate the requests, but I don't know/understand how to trigger this form of authentication
you can store that session_id on server cache, as a static hashmap variable, with unique key
After finish transaction, you have to remove value by key
Related
If a user authenticates via OpenID Connect on a client and triggers a long-running server-side request, how can the server keep the access token valid if the operation takes longer than the access token's expiration time?
We have an application suite consisting of several server-side backend applications (typically accessed via REST, HTTP, and/or WebDAV), several web frontend applications and several client-side (i.e. desktop) applications. We already support the Basic and Kerberos/Negotiate authentication schemes and are currently adding support for OpenID Connect.
Our backend applications are typically accessed by the web frontend and client applications, other server-side backend applications, and 3rd party customer applications when our software is integrated into their system. We currently pass OpenID access tokens via the Bearer scheme to the backend applications.
In a typical scenario, a user (authenticated on a local client or in a web frontend) triggers a server-side operation which may possibly run for several minutes, hours, days, or even weeks. This operation accesses other backends on the user's behalf, e.g. a Web-DAV based server-side file system, to access additional data. All backend applications need the user's authentication information to grant access and access further user details for authorisation (e.g. to only grant access to the user's own files).
Obviously, this means that the access token provided with the original backend call may expire before the operation is completed. The server therefore needs a way to refresh the access token without user interaction. Our code can already do this if it knows the user's refresh token (using the refresh token and the application's client ID and secret to access the OIDC Token endpoint).
But how can we "correctly" pass the refresh token to the server?
The client has (potentially) the full set of ID, access, and refresh tokens. But from what I understand, the Bearer scheme expects that the passed token is the access token. Compatibility is important here, since our backend applications may also be accessed by 3rd party client applications. Assuming that getting the refresh token into the server application is the correct approach at all, we therefore still have to support situations where the caller can only provide an access token (with the obvious implications that in these cases, long-running operations will not be able to access other backend services on the user's behalf).
I could imagine the server accepting either an access token or a refresh token via Bearer. But from what I understand, the only "argument" a client may pass with a correct Bearer authentication header is a single Base64 encoded string, i.e. the (access) token. The client could pass an access or refresh token here, but I don't see how the server could then tell which it is, as to my knowledge both token types are opaque.
I understand that the original idea is for server operations to be short lived, so that keeping the access token up to date is the client's responsibility. But surely we cannot be the first who do need to combine OIDC with long-running server-side operations. Is there an accepted way to pass a refresh token to a server, or, alternatively, a completely different approach that I'm missing?
We are investigating using SignalR in our app for messaging. We want setup this messaging system as an app on its own. So our all our applications will connect to this messaging app to send messages. All this works fine but I am not sure as to how we can secure the SignalR messaging app. We only want our app to connect to it (basically our app users). If there are any other connections trying to connect, we want to reject this connection. Currently we set a query string parameter which can be validated on the server side but I am not sure how we can do our validation before the connection is made. I know in the hub we can override the OnConnected but this is too late. I want to refuse the connection before it starts.
Can someone point me in the correct directions.
We do that in our ASP.NET application. We have implemented an authentication module. We validate the cookie and the user in there.
My .NET web app presently uses Azure Windows server VM to receive and send SNMP email. My users send email to my web app, and my Windows server VM receives this email into its SNMP and then deposits it into a folder, which gets read by my backend .NET app.
I'm interested in switching to the new Azure web app model, but can't find anywhere how it would receive email.
My DNS provider uses my MX RECORD configuration to forward email from my users to the IP of my present VM server and then to its SNMP receive service, etc.
To receive email with a Web App in Azure App Service, you can setup a Web Job that can poll for new emails on a Schedule or Manual trigger, then perform a custom action necessary.
Another alternative is that you could create an Azure Logic App that is wired up to be notified of email messages. This can be done using the Outlook connectors (if you're using an Outlook email) or other connectors. Then the Logic App can be setup to make an API call to your app to trigger some sort of custom action to take place for emails received.
The configuration you have today on a full VM can not be implemented in Azure App Service Web Apps. The underlying managed VM that hosts the Web App isn't accessible and configurable in this way.
I want to create the web application (SPA with angular) with token based authentication.
It is required create the access token with short live-time, perhaps 1 hour expiration.
I want to use the SignalR for real-time communication and I have tried send the access token via query string after starting signalr connection.
If is access token expired I create the http request for refresh it and recieved it to the javascript.
How can I send the new access token if is signalr connection is running?
Is possible change the token or is necessary close the connection and create new again?
It depends on the transport technology that is used. In case of websockets you have to stop the connection, set the query-string and restart the connection. With other technologies you can directly change the query-string. You can check $.connection.hub.transport.name to learn what transport method is being used.
I've been trying to work out if it is possible to authorize communication between a mobile app and my ASP.NET web api service without the user having to authenticate with a username and password. This is important because users of my app don't login at all and never will. All traffic will of course be sent over HTTPS.
This means I can't use OAUTH or BASIC authentication to authenticate the traffic as these require credentials.
So I need some method to securely store some kind of authentication token that is packaged in the app that is only accessed when it needs to communicate to the server and can't be "discovered" by a determined hacker.
This may of course not be possible.
Thanks.
In general it is not possible. Your server should never trust it's clients. Hackers can examine your client app and create equivalent one.
But you can make life of hackers significantly harder, if you:
Use custom cliest sertificat for HTTPS, look here.
Use temporary access keys in http request. Application should request for new temporary access key your server. Part of the key server will send in response and another part will be sent via Cloud Messaging. Combine parts of the key in some non-trivial way.
Obfuscate your app.