So what I need to do in my application for loggin in is Perform an HTML request with user/pass which returns XML with a token. The token is used in later http requests.
I know how to perform http requests and also how to parse them, I have already been doing that just with the token hardcoded for testing purposes. I also have it worked out how to use the Application Preferences to allow entry and retreval of the password via:
NSString* settingValue = [[NSUserDefaults standardUserDefaults] stringForKey:#"<Setting Key>"]
The question is if I want this to happen when the application launches where shall I do this? I don't want my application to hang when it launches without giving some feedback to the user, you know if there is no user/pass set or if its rejected by the server. What is your advice? Thanks
In the app that I am developing, I do it in the first view in a separate thread. This way it doesn't lock the UI. I also do it as a delegate of the main view so it can report back the progress for a progress bar. Later on I'll will be doing it as a slide in view thats just shaded so the person can use parts of the app that don't require auth while the auth is loading.
IMO if you do it in the app delegate it might take several seconds for you to auth and you will not be able to report this to the user easily.
The best way to deal with authentication is using cookies as you are using HTML requests. You can retrieve these cookies using NSHTTPCookieStorage app wide (not just in the class that did the authentication). If you want to continue using your token you can create a global variable in your Application Delegate class (myApplicationAppDelegate.h)
P.S, I wouldn't keep the username and password in NSUserDefaults as its stored in plain text on the device. Use keychain instead.
Related
I am new to WIF.
And now I encountered a problem when performing single sign off.
The following is the background of my problem:
First of all, I am working on two old application A and B, which they stores the user's information in their own session variable after authenticating a user. And App A and B have their own local database. Now, my work is to use ADFS to enable SSO (Single Sign On) between two applications.
Now, I create a new active directory to store the users centrally.
When a user try to login application A through ADFS, application A need to check the user name in the claim is exist in the local database. If exists, the user can login to App A. Otherwise, App A will reject the claim.
Here is the technical part:
I extend the WSFederationAuthenticationModule and check the incoming claim with the local database in the method OnSessionSecurityTokenCreated. If the result is matched, I retrieve the user information from local database and store it in the session variable (so that i can minimized the code change). App B uses the same approach.
I am happy with the SSO from here. But the problem come when i perform single sign off:
When I logout from App A, i first clean up the own session in App A and call the WSFederationAuthenticationModule.FederatedSignOut method. However, App B do not clean up its own session. I suppose the OnSignedOut in WSFederationAuthenticationModule will be invoked. How can i clean up the App B's session when App A is signed out?
It may be very confusing. Please leave any comments if you find something unclear or need further explanation.
Signout in WS-Fed is implemented by ADFS (it asks for a gif with app/?wa=wsignoutcleanup1.0), not only locally. That is the only way to notify the other app.
Your app has to to redirect to ADFS with a signouturl. Then both apps will be notified and can cleanup their session state (with the gif request).
Hello, everybody.
I am developing an iPhone native app(including webview in it) which could communicate with my server-side webservice.
The system has user management module which user could login/out, chanage theirs own information.
Come with usual cases such as a web site, there must be token or something else for security consideration.
Then what about iPhone native app? Because my webservice could only access from the app so that I think it is secure enough, is it also necessary to implement at the session token way?
Thanks, Best regards.
How are you going to do identification/authentication without token?
I believe when you enter User/Password the this authentication pair + device_id is sent (using SSL) to the server, then in case of successful authentication server returns session token (session could be unlimited by time, it is up to you) for this device_id. Login and token are saved somewhere in your program (e.g. in defaults key/value storage). Password should be never saved anywhere in program.
When user launches your app, app sends Login, token and device_id to the server, server checks and say OK+session_key or NOK. In case of NOK you delete login and token from your app's storage and display login form again. If response was OK - you send HTTP requests + session key and server replies you. Something like that...
PS: I believe it should be like that, however I don't have much experience in Web.
I'm creating an iphone app where the user logins once (when they open the app for the first time), then will never have to login again (like how instagram does it). The app will automatically log them in the next time they open it up. However, the app makes a bunch of requests to a web server.
What is the best way for the server to issue session tokens? How long should the session tokens be valid for? How can I ensure the user never has to log in again, while still providing secure session tokens.
One approach is for the server to issue a token to the user when the user logs in for the first time, and make that token permanent. That, however, does not seem secure.
Thanks for the help!
Well, generally the session is already handled through session cookies. Unless you're planning to have third parties connect to your service, I think it's a bit overkill to do anything besides basic http authentication. I would definitely send all of your connection requests over an https connection though.
As far as persisting the session on the iPhone side, you can save the user and password in the Keychain, and then automatically retrieve and send it to the server when it requires you to log in again, without having to prompt the user to log in again. How often you want the sessions to last on the server end is really up to you.
What is the best way for the server to issue session tokens?
One way to do it is using OAuth. It is more complex than cookies but it has more features.
A token is granted to each application and can be revoked by the user from a page in the server. This token can be permanent or temporary. You can store it as plain text or inside the iPhone keychain, depending on the level of security you need. There is open free code for server and client implementations. Another benefit is that clients can log in your service using their Twitter/Facebook/... account so they don't need to register on your site.
I'm building an app that performs similar functionality that one website does: register, login, submit order, view orders and etc. Now, do I have to do anything explicitly in order to get things working?
After successful login, a webserver establishes a session and sesssion ID and related session info is written to related cookie. IMHO, I just need to call webservice with login credentials and then the rest will be done implicitly. After successful login, every requested user page from user area will be checked with sent cookies and session file at server side. So, do I have to do anything else in order to get into secure area?
Agree with what #sicKo has said. Remember, sending data over wireless network is not secure. Do be careful on the transactions when money and authentication involved.
In addition to what #sicKo has said, you may now consider the coming iOS5, store the value at iCloud.
You just have to send the value to verify the user to the webserver.. and u can keep the session alive in iPhone using NSuserdefault..
U might want to encrypt the sensitive data send over the network such as username and password.
I am making an IPhone app in which
userid and password is required in
all the screens to make requests to
the server, and I am thinking of
saving those 2 values in
NSUserDefault instead of passing an
object around.
I am also thinking it will be useful if user has logged in once,
and use the app again then user
don't have to enter his/her details
again.
But I am curious if it will be safe/good practice to use for first requirement?
I don't have anything against save these data on the user defaults. What I don't get is the idea to expose the user credentials on each request.
I would suggest you to ask for the credentials once, authenticate with your server and return a "session token". save this token and use it to validate the user on each request. (it means that you will save the token on you server or you will check the token using an algorithm)
Doing this you don't expose the user credentials all the time, you have control over the session, and you can expire it when you want, forcing the user to logging again.
For more complex implementations, you could Google for OAuth or XAuth and some related methods of authentication.
Cheers,
vfn
It's reasonable to save global values in NSUserDefault that you want to survive your app being killed and restarted (as can happen under iOS4.0).
Passwords should be saved in memory (maybe a singleton model object), or in the keychain, as various iTunes backup databases might expose stuff stored in user defaults.