I have 2 web application on different wed servers: Core (Spring 3.0.5, Spring Security 3.0.5, PostgreSQL) and Red5
I need to develop the next workflow:
User logins in Core
System returns web page with simple html and flex app
User streams audio on Red5 by flex app
Red5 uses Core to check if user is logged in
Red5 sends file to Core
Core identifies that a file come from appropriate user
Core stores file in related user's folder
I have configured Spring Security at Core, flex client which streams audio to Red5, servlet on Red5 which stores audio in flv file and have access to this file.
My idea is:
In case of successful login Core returns sessionId
At the end of recording flex app sends sessionId to Red5 server
Red5: makes http get request with sessionId to Core
Core returns "true" in case of user was logged in
Red5: makes http post request with 2 parameters: file and sessionId
Core identifies user and stores file in user's folder
Please provide mechanism how to get this sessionId, how to check if user is logged in and how to get user by this sessionId or better approach to implement described workflow
Related
If you have an on-device application (e.g. desktop program, mobile device app) you can use OpenID Connect with some caveats:
Using Resource Owner Credentials (grant_type: password) is the simplest, but might not be possible if the authentication server operator won't let you use that grant-type because of trust reasons (i.e. they don't want you collecting the user's username+password yourself) - or if they have a dynamic or custom authentication UI that would be hard to replicate in a native app.
With the interactive flows (implicit, hybrid) the authentication sever's authentication page is shown in an in-app web-view. Most users will have no idea that the application can snoop on the authentication page and capture their username and password, especially on mobile devices - but this way the application code can easily capture the authorization code and/or access token, and automatically dismiss the web-view without any additional user interaction. (I'm surprised I haven't heard of more cases of users' details being captured by malicious apps this way.)
...so the advice is to always open the authentication page using the system's web-browser, but on the Windows desktop there is no good, standard way for the system web-browser to return the server response to the application code, though there are a number of approaches currently in use:
The authentication success page instructs the user to copy and paste a blob of text (containing the authorization code or access_token response) back into the desktop application.
Show the page in an app-hosted web-view, as per the notes above.
If the authentication process always only needs a username and password (for example) the application could still capture the user's username and password with its own UI and then make its own HTTP requests to make it seem like a user's web-browser session, and get the authorization code and/or access_token that way.
On Windows only:
Have a small utility program authHelper.exe that when invoked forwards its command-line arguments to a named-pipe in the user's session.
The main client-application will register authHelper.exe as a temporary URI scheme handler in the per-user HKCU\Software\Classes key, e.g. my-application: such that the contents of any my-application: URI are passed as arguments into authHelper.exe.
The URI passed to the system web-browser to open the authentication page has the redirect_uri parameter set to my-application:, so after the user authenticates in the browser, the browser will request the custom URI scheme which is handled by Windows, which invokes authHelper.exe "access_token=..." which then sends the data down the named-pipe to the running application.
If the user doesn't have permission to write to their own HKCU\Software\Classes key, or if they're using a version of Windows that doesn't support custom URI scheme handlers with EXE registrations then this doesn't work.
Windows UWP applications can also use the Web Authentication Broker.
I was wondering if a different approach could be used: why can't the application simply poll the authentication server for the status of the authentication attempt? Or does this approach already exist, and if so, what is the name of the flow or grant?
Here's the flow I'm proposing:
When the user wants to authenticate, the application opens the system web-browser as before, but with another parameter for a one-time-use opaque ID provided by the application.
As soon as the system browser is open, the application makes requests every 500ms or so (i.e. a polling loop) to the authentication server using its own HTTP client that asks for the status of the active authentication attempt associated with the same opaque ID as before.
The initial few responses from the authentication server to the application will presumably be status: pending, but eventually after the user successfully authenticates within a timeout window then the application's poll request would indicate a successful attempt and also contains the access_token or authorization code as is applicable. If the user failed to authenticate (e.g. 3 incorrect attempts) or left the window open long enough causing a timeout then the poll response would indicate failure.
Does this already exist and does it have a name? Are there any potential security risks or vulnerabilities with this approach?
It exists and has a name, "OAuth 2.0 Device Flow for Browserless and Input Constrained Devices", but is not yet fully standardized, see: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow
Google also implemented this flow avant-la-lettre in a vendor-specific way:
https://developers.google.com/identity/protocols/OAuth2ForDevices
We are building a desktop client(using Electron framework) which will communicate with a remote server via REST API. We want our desktop client to be in the logged-in state for an infinite time.
I am aware of this fact that credentials of user need to be stored securely for this purpose.
But how can we achieve this Electron framework so that it renews user session continuously on session expiration?
You would use the Webstorage, generally, it is the same behavior as for example facebook does, your browsers saves some kind of authentification token.
But this also has a drawback because it can be stolen through XSS, one trick to prevent this while still beeing logged in infinitly is to update the token on each connection to the server, also make sure to use HTTPS otherwise the token can be grabbed from the network connection.
// write to storage
localStorage.setItem("lastname", "Smith");
// read key from storage
console.log(localStorage.getItem("lastname"));
// delete key from storage
localStorage.removeItem("lastname");
I have a client - server application. Client (iOS application) has to download content from the server. Is it possible to determine if request is from the application downloaded from the App Store of just regular request (should be dropped)? Is exists a possibility to avoid hardcoded credentials in the application?
Thanks
Is it possible to have a WinForms application make a simple call to an Mvc app over the wire to carry-out a simple query (into a controller > service > repository)? I'm wondering whether it should provide a service api controller, separate to the rest of the application which spits out the Json to the WinForms application, or should it go the WCF/WebService route?
It needs to be able to authenticate too so the end solution is secure. As the WinForms app needs to poll the end-point, I don't want to send the username/password in each request. Can there be some provision for a session on the end-point which times-out and then requires a re-login from the client?
Yes, you can use the System.Net.HttpWebRequest and System.Net.HttpWebResponse classes to create an HTTP client. See here for an example.
Web apps do have a session timeout which starts counting when there is no activity on a session. So, if you do not want to be re-authenticating on every request, you will need to echo the cookies that the server sends to you in HttpWebResponse back to the server with the next HttpWebRequest, so that the server knows your session and keeps you logged in. If you erase the cookies, you will need to re-authenticate. If you do not interact with the server for a while, (usually about 20 minutes,) you will also need to re-authenticate. (Assuming that your WinForms application will not check the 'remember me' checkbox on the login form.)
I'm using Flex 4(beta2) with Ruby on Rails 2.3.5 and using RubyAMF to transfer data back and forth between Flex and server.
I set up Authlogic on the Rails side for authentication.
I wasn't sure what's the best method to handle user sessions. I know this is done automatically with Rails by sending session id with cookie which Rails use to authenticate the user.
What do you suggest the best way to do this with Flex?
I thought of couple of options:
1. Manually fetching the cookie from the browser and then figuring our a way to send that to the server with every request I send.
2. Handling sessions expiration and flow on Flex side by manually expiring the session
Do you have other suggestion or recommendation?
Thanks,
Tam
Network requests in Flash use the browser networking stack so cookies in Flex work just like any other browser application. Usually authentication in Flex is no different than it is with a standard web application. Send credentials to the server which it correlates with a session id. Every subsequent request (RemoteObject, HTTPService, etc) also sends that session id.
We have seen that the flash plug-in propagates the session cookie when we do blazeDS (http) remote calls
In the past we have worked with BlaseDS and HTTPServices. In both the cases the request is sent to the server over HTTP. Our server stack as Java (JBoss to be specific).
We noticed that the flex client used to send the session information with the requests to the server. We used same information to store and fetch Principal on the server.
In one case, we propagated the token to the client. This was to avoid multiple submits for same requests - hence we used the common HTML submission approach of token generation where with every response carries with itself a new token and the client has to sent it back to the server for executing the next request.
For the session expiration, there is a good chance that a user is working on the client for any local needs and not working with the server which may have caused a expiration on the server without impacting the server. In this case, we disabled the session expiration on the server and wrote custom code to handle events - keyboard and mouse on the flex client. If the application was not used for a specified time, the flex client would expire both the sessions i.e. local and server
What do you suggest the best way to do this with Flex?
$loggedIn=Authenticate::isAuthenticated();
if(!$loggedIn)return false;
$user=Authenticate::getAuthUser();
First Authenticate the user and if he is logged in create the session. Include this in your every PHP or Ruby file, and check it. Send the Session ID to Flex to maintain the state and you set the time for your session to expire.
The above code does check, whether the user is authenticate to access the PHP or ruby class files.