The CAS system is designed in a way that the administrator of the server needs to provide a list of services (URLs) that are allowed to use the CAS. This means, that by login in you'll get a TicketGrantingTicket (TGT) which can then be used to create ServiceTickets (ST) to authenticate to a specific service.
This causes some problems when you try to authenticate an APP on a cellular phone which usually does not have a fixed name or IP which could be registered on the CAS server. However, CAS offers the possibility to allow the generation of TGT and ST via a RESTful interface.
As you have probably seen in my previous posts our CAS comes with a set of customisations to fit into our needs of which the integration of a login-domain is probably the most complicated. Introducing such a new, third field for the authentication causes changes throughout the code and as it is needed now to generate TGTs and STs it needs to be implemented in the RESTful interface as well (see my link above for details)
The general usage of CAS's RESTful interface is stated in the CAS documentation, so I'm not going to copy it to this blog, but the interesting thing is its implementation into an iOS application which is not present there.
The general idea on how it can be done comes of course from the CAS documentation and by adapting this article about how to connect Drupal, CAS and iOS. My solution is partially copied from there introducing a newer more powerful API for consuming the RESTful WS and our new Domain field.
Actually the project does just the creation of the TGT and an ST for a sample service and returns the result after executing the "serviceValidate". This means that after this step we know on the iOS-APP exactly who logged in and all other attributes that are provided by the CAS.
What's still missing is a general solution on how this iOS-APP could authenticate itself now to an arbitrary web server like DRUPAL in the post stated above.
The sample project is hosted on github