I am working on a problem statement, where we are trying to create SSO system. For that SSO system, in order to create a SSO session for a user, we need to have a unqiue identifier which is same for all the apps in the device. So that, the server can identify that user has a existing SSO session for that device or not?
TLDR:
Looking for a unique identifier for all the apps in the device.d
I tried looking into ANDROID_ID, but got to know that it is combination of signing key, user and device. Hence, it will change for each app.
Related
Can Google Sign-In be used on an iPhone app in conjunction with Touch ID? If so, how? I cannot find any examples of this being done or talked about online.
Apps can incorporate TouchID as a means to locally authenticate a user.
Basically, the TouchID system can be queried and will let you access items in a keychain or do a simple one-off authentication.
If you stored Google account credentials in a local keychain, you could use TouchID to unlock the local keychain item, and then pass that item to a Google service for Google's authentication.
The keychain item in question (a password) would have to be enter manually at least once by the user (and at that point, it is probably more straightforward to just request an reusable authentication token from Google).
TouchID is entirely a local system, no fingerprint data is ever exposed to third party developers or pushed to a network, so Google couldn't store a fingerprint in their servers and allow direct authentication against their services using TouchID.
Here's the framework reference for Local Authentication:
https://developer.apple.com/library/ios/documentation/LocalAuthentication/Reference/LocalAuthentication_Framework/index.html
The Local Authentication framework is best suited for either confirming a logged in user in an app where the user may be logged in between many sessions (such as for a purchase in a shopping app) or local authentication for local documents (such as for password protected note taking apps).
I have two web applications. Today they both have their own way of authenticating users and storing their credentials. Some of my users use both applications -but their usernames/passwords may be different in each application.
I would like to introduce a single-sign-on solution for these application so my users only need to worry about a single username/password.
What is the best way to migrate these applications into an SSO solution? Specifically, how do I securely associate a user in Application A with their respective user in Application B?
For one user, since the usernames may be different in each application, I don't think I can run a script a 'merge them.' I would prefer the users elect to merge their accounts and prove they own both accounts. Can OpenId Connect help with this problem? After authenticating with App A, I can ask if they would like to pair App B to their credentials in App A. They would then be redirected to authenticated to App B. If successful, it would redirect back to App A with their App B username in an OpenId Connect token. The SSO solution would then store their App A and App B credentials together as a pair. In the future, local app sessions with each application can still be creating using their legacy username but the user only deals with a single SSO username going forward. Thoughts? What are other approaches to solving this problem?
I'm not concerned about the cookie/cross-domain issues. I'm most interested in how to reconcile the usernames across both systems.
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).
I am creating an application which is like a template where every service provide can enter their details in the setting on the web and just change the app name ,app icon, new bundle identifier and upload the app on app store.
Till here it was good, But the problem for me is that I have a push notification services in this app.
And I have read on the apple document that every bundle identifier should contain a unique push certificate. And from there we create a .pem file, so that means every app will have a different- different pem file.
But I want a single pem file which will work for all app.
Can anybody please suggest me what should I do, or what is the proper way to go about it?
Unfortunately, what you are asking for is not currently possible with Apple Push Notifications Service. Though you could conceptually use several of the optional arguments in openssl to generate a Certificate Signing Request (CSR) using the exact same keypair, the root issue comes from the 'Certificates, Identifiers, and Profiles' tool in the very first step in creating a new APNS certificate:
As the supplemental instructional text reads: "Note that only explicit App IDs with a specific Bundle Identifier can be used to create an [sic] Push SSL Certificate", which means that we can neither provision a Wildcard App ID for push notifications, nor can we specify 'All App IDs'.
If we briefly step into a hypothetical world where the "Which App ID would you like to use?" question doesn't exist and instead went directly to the step where we upload our CSR, the certificate we would get back from Apple would do exactly what you want -- It would authenticate the server you use to construct APNS payloads as one legitimately belonging to you and authorized to send pushes to the APNS Gateway. It does, however, open an important security concern -- If you can use this one server (or 'provider' in APNS parlance) to send pushes to any of your apps (so long as you know the device's APNS token), what prevents you from using your provider to send pushes to my apps? Or if we turn the concern around -- what would prevent me from using my authorized APNS provider to send your apps push notifications? Or to send pushes to your customers with misinformation (ex. 'Regrettably MyApp is closing its doors and exiting the App Store. MyApp recommends customers purchase CompetitorApp to maintain your service!'). This slimy, scam-prone world we thankfully don't live in...
Instead, Apple requires 3rd-party developers to select the AppId for which payloads from a particular APNS certificate will be honored. Then even if I somehow manage to acquire your customer's app's device token, I won't have your server's private key and thus could not successfully deliver a scam, spam, or otherwise rogue APNS payload to your customers.
Ok, I got it already! Since I can't use a single certificate for multiple App IDs, what can I do?
Given some of the background in your question, it sounds like you've put in the effort to make your app highly configurable. In your own words "[it] is like a template" - which would suggest that on the server-side of your app, you have some mechanism in place to be able to be able to identify what app is making data requests and which provider's data to send back. Your APNS Provider logic would need to have similar intelligence built in. Depending on how you are currently making these server-side distinctions, you may be able to reuse some of the existing logic; you are the one who will have to make that call. The remainder of this answer will offer a high-level approach to how you might choose to setup your provider owing to the one-pem-per-app requirement APNS imposes. In general:
Place a copy of the signed .pem in a secure location on your APNS Provider
Update your Provider's 'register device token' API to accept both the device token as well as some way to uniquely identify the app for which this token is valid (...maybe as simple as just the App ID itself!)
Update the iOS App to pass both it's APNS device token and that App Identifier to the freshly updated 'register device token' API on your provider.
Update your Provider's logic to use the correct .pem when delivering a payload to the APNS Gateway.
For the sake of good process, ensure that you have a procedure to update or retire an application's .pem, data, and relevant tokens.
For each app that you make from your template, you already have to generate a unique App ID and App Store Distribution provisioning profile. When doing this initial setup, you can also request the APNS certificate and treat all three pieces of data as app-specific settings. Install the APNS certificate into your provider along side the .pem file for your other apps so that you can grab it when it comes time to send an APNS payload to Apple.
If you've done APNS work before, you know that your provider is responsible for tracking app-specific device push tokens, generating and transmitting the APNS payload to Apple, and optionally using information from the APNS Feedback API. When your app connects to your provider to register its token, you'll also need to know for which app that token is valid so that you can select the right .pem for sending APNS payloads. This is key; if you don't have a way to know which tokens go with which App IDs then you will be unable to select the right .pem file during payload generation and dispatch.
Updating and retiring software is a key part of all software, but is one that doesn't always get the attention it should. Make sure you've considered how you'd go about refreshing the .pem file (which you'll have to do each year before the current one expires) as well as how you'd go about retiring an application without disrupting the other apps your provider services.
The answers to each of these questions is very much dependent on how you've architected the various components of your app, Xcode project configurations, server-side technologies, and server-side logic. Only you, or your team, can make the right call based on the details that make up your software. Best of luck and let us know how things go.
I'm developing an HTTP api for our web application. Initially, the primary consumer of the API will be an iPhone app we're developing, but I'm designing this with future uses in mind (such as mobile apps for other platforms). I'm trying to decide on the best way to authenticate users so they can access their accounts from the iPhone. I've got a design that I think works well, but I'm no security expert, so I figured it would be good to ask for feedback here.
The design of the user authentication has 3 primary goals:
Good user experience: We want to allow users to enter their credentials once, and remain logged in indefinitely, until they explicitly log out. I would have considered OAuth if not for the fact that the experience from an iPhone app is pretty awful, from what I've heard (i.e. it launches the login form in Safari, then tells the user to return to the app when authentication succeeds).
No need to store the user creds with the app: I always hate the idea of having the user's password stored in either plain text or symmetrically encrypted anywhere, so I don't want the app to have to store the password to pass it to the API for future API requests.
Security: We definitely don't need the intense security of a banking app, but I'd obviously like this to be secure.
Overall, the API is REST-inspired (i.e. treating URLs as resources, and using the HTTP methods and status codes semantically). Each request to the API must include two custom HTTP headers: an API Key (unique to each client app) and a unique device ID. The API requires all requests to be made using HTTPS, so that the headers and body are encrypted.
Current strategy:
My plan is to have an api_sessions table in my database. It has a unique constraint on the API key and unique device ID (so that a device may only be logged into a single user account through a given app) as well as a foreign key to the users table.
The API will have a login endpoint, which receives the username/password and, if they match an account, logs the user in, creating an api_sessions record for the given API key and device id. Future API requests will look up the api_session using the API key and device id, and, if a record is found, treat the request as being logged in under the user account referenced by the api_session record.
There will also be a logout API endpoint, which deletes the record from the api_sessions table.
Does anyone see any obvious security holes in this?
I agree with the oAuth comments - you can of course make oAuth work nicely on an iPhone - the UX is totally up to you. There are mechanisms (jQuery) to pull back the PIN from oAuth and use it (without the user re-typing the PIN into the app). That reduces the UX to
1) Display web page (in embedded control)
2) user enters user and password and presses button
3) oAuth response page is parsed automatically.
This twitter oAuth implmentation does that http://github.com/bengottlieb/Twitter-OAuth-iPhone using a pre-existing oAuth library.
However, back to your original question. That looks fine. The only item you don't mention, is that you need to provide a mechanism on the web app to allow the user to logout/deauthorize a device session (in case they have lost their device).