Single Sign ON (SSO) in iOS 7

SSO is a new native feature in iOS 7.

You can find next there:

Enterprise single sign on. Authenticating into corporate apps is now as simple as doing it once. Enterprise single sign on (SSO) means user credentials can be used across apps, including apps from the App Store. Each new app configured with SSO verifies user permissions for enterprise resources, and logs users in without requiring them to reenter passwords. It is something like single sign in for several apps.

To make SSO (Kerberos) working on iOS7 you need 3 things:

1. On the server side: Kerberos environment + HTTP SPNego/Kerberos authentication configured. SSO in iOS works only for HTTP(S).
2. Configuration profile containing:
   • [Obligatory] Your Kerberos realm.
   • [Obligatory] Your Kerberos principal (usually username), this can be left empty - in that case user will be asked to specify it during the profile installation.
   • [Obligatory] List of URL prefixes of the pages allowed to use SSO. Wildcards cannot be used here, if the prefix doesn't end with slash character, it will be automatically appended to it.
   • [Optional] List of bundle IDs allowed to use SSO, if empty all applications are allowed. Wildcards in bundle IDs can be used.
3. Application that supports it, Safari and WebKit (UIWebView class) do. As described in WWDC 2013 Session Videos number 301, you have to use either NSURLConnection or NSURLSession class. This is a simplified example of the HTTP traffic when authenticating using the SPNego scheme:

Client: GET https://login.example.com/adfs/ls/auth/integrated/?data1=aa&data2=...

Server: 401 Unathorized

+header WWW-Authentificate: Negotiate

Client: GET https://login.example.com/adfs/ls/auth/integrated/?data1=aa&data2=...

+header Authorization: Negotiate [SPNegotInitToken]

Server: 200 OK

+header Authorization: Negotiate [SpnegoTargToken]

+header set-cookie [SESSIONID]

The dialog with prompt for the Kerberos password (if the Kerberos ticket has not yet been granted/expired) will appear after receiving "WWW-Authentificate". Obj-C classes will handle automatically all the redirects and authentication process, so the only thing you need is to make a request to the login URL and allow this URL in the profile.

It is now possible to check the version using available from Swift2.0.

if #Available (iOS 8.0 , *) {
     // IOS8.0 more if only the processing of
}

The syntax is as above, #Abailable (Platform version, ...) will be.
At the end * indicates that "otherwise specified with respect to other platforms." 
In other words, in the example above, iOS other than the platform (WatchOS,OSX will be that it is not specified in particular with respect to, etc.).

In addition, when the processing of post-conditions specified is large, it would be good to use the guard statement because the contents of the if statement would parentheses bad increases.

guard #Available (iOS 8.0 , *)  else {
     Return
}

Processing of // case of iOS8.0 or more only

Conversely, self-made method in order not to be used outside the platform version that you specify and classes available (platform version, ...)should be used.

// IOS7.0 and Yobe not only from later 
Attoavailable (iOS 7.0 , *)
funk doSomething () {
    
}

Thus available With this method when you call the #available will require conditional expression.

if #Available (iOS 7.0 , *) {
    doSomething ()
}

Reference article
www.hackingwithswift.com