[Openid-specs-native-apps] TA Discovery

Thu Nov 27 20:44:21 UTC 2014

Yes having a MDM provision down the information to the app would be the preferable option.

I don’t think all TA using the same URI is necessarily the correct thing.   There may be cases where you have a social TA for some apps and a enterprise TA for other apps on the same device.

Will some IdP be willing to share token agents in the social case.  That may be true if it is part of the OS, but perhaps not if it is an app.  Also native app TA will need client credentials for each IdP as well.

At the moment we have an assumption of one uri scheme for invoking the TA.   Bad things happen if you get two TA installed by mistake. 

If we have multiple TA they need to use the system browser to share state or be dedicated to an IDP if they are using a embedded web view.

John B.

> On Nov 27, 2014, at 5:12 PM, KabirBarday at air-watch.com wrote:
> 
> On iOS the common URL scheme may have some issues, iOS allows multiple apps to register the same URL scheme and will auto select one, the user does not get to pick. The logic for which app iOS selects is arbitrary. This also opens up a security issue where a malicious app may be installed, registers for the TA url scheme, and then intercepts the credentials the end user enters in the fake TA.
> 
> With MDM, both iOS and android have the ability for MDM vendors to send app configuration into the app. On iOS it is called managed NSUserDefaults, and on android it is called App Restrictions. The configuration can indicate which TA to use in some way, and there is a standard way for app developers to listen to these configs on both iOS and android (Msft is working on a similar approach also). This may make it a better user experience when deployed with MDM, but will need some fall back logic when no MDM in place. 
> 
> 
> Kabir Barday
> C | 404.913.4120
> KabirBarday at air-watch.com <mailto:KabirBarday at air-watch.com>
> 
> Sent from my device managed by AirWatch
> www.air-watch.com <http://www.air-watch.com/>
> 
> On Nov 27, 2014, at 10:10 AM, Mike Varley <mike.varley at securekey.com <mailto:mike.varley at securekey.com>> wrote:
> 
>> Hi John,
>> 
>> I believe you have highlighted 2 different scenarios:
>> 
>> 1) A closed ecosystem, where a large organization has several apps that rely on a single token/authenticationagent. (lets say all Apps and the TA have the same brand)
>> 2) SaaS Apps that want to leverage a user's token agent, but are multi-purpose (mail service, doc management, etc…)
>> 
>> in (1) I believe hard-coded custom URL schemes or custom discovery systems will work fine. The closed ecosystem sets the rules and follows them.
>> 
>> So considering (2), the SaaS App needs to discover a TA. And there are a couple options:
>> 
>> (A) All eligible TA's register for the same scheme (e.g. nativeapp://)
>> (B) SaaS App need to be able to customize themselves for a user's organization
>> 
>> I see (A) as being a more flexible option, if the corners aren't too sharp. For example, if I as a user have installed Box, and have 2 TAs installed (one for work and one for a club I am in), then when Box launches, it invokes the common URI (nativeapp://authorize), and on Android I think this will allow the user to select the TA they wish to use. The advantage here is Apps and TAs have very clear, simple requirements to be NAPPS enabled. The problem is, I don't think all the mobile OS's treat multiple apps registered for a URI scheme the same (i.e. can anyone confirm that on iOS, the 'latest' App to register for a scheme becomes the default?).  
>> 
>> If mobile OS's are not going to allow for (A) (cleanly), then (B) is the better option, and a bootstrapping process described below is reasonable. A few thoughts on the process:
>> 
>> - should the user authenticate to the endpoint before the ecosystem config is released? Would it make sense that a SaaS App allows the user to login in with OpenID Connect, and part of the id_token/userinfo then contains the TA information?
>> 
>> - does this mean a user must bootstrap *every* SaaS App on their device to use a TA? [ seems like a painful process ].
>> 
>> - how much extra dev work are we imposing on SaaS Apps that may want to be NAPPS enabled?
>> 
>> 
>> Thanks,
>> 
>> MV
>> 
>> 
>> 
>> On Nov 26, 2014, at 5:12 PM, John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>> wrote:
>> 
>>> At IIW this was one of the questions that we didn’t get to other than to say that it is required in some way.
>>> 
>>> A napps client needs to know what TA to invoke.  
>>> 
>>> If there can only be  one TA on the device and they all use the same custom scheme then I suppose that discovery is moot.
>>> 
>>> If we have a SAAS app like box then I could see wanting to customize the TA per enterprise.
>>> The app could call a well known endpoint and get the config for the enterprise eg custom URI to invoke.  (The app wouldn’t have credentials at that point so this would be public.)
>>> 
>>> The other sort of app may be a generic app that uses a standard API at the enterprise, but doesn’t know who the enterprise is without some bootstrap.
>>> 
>>> One way to deal with this is to have the user enter a domain to bootstrap the app.
>>> 
>>> It can then use a similar  process to Connect discovery to find the enterprise napps config file in .well-known.
>>> The file would list the client_id and custom scheme for a token agent and a fallback https: URI for using the browser.
>>> 
>>> This requires the same infrastructure as they would already have in place for Connect Discovery. 
>>> 
>>> This also works for the saas app as long as the enterprise publishes the discovery doc the saas app could pick up the config info.
>>> 
>>> The downside of the SAAS publishing it, is that they generally don’t like publishing lists of customers.
>>> 
>>> Are there other things that need to be discovery at this stage. 
>>> 
>>> I think NAPPS discovery should start as a separate document and we can merge them later if we want to.
>>> 
>>> Not all apps will need it, some can be hard coded if they are developed by an enterprise directly.
>>> 
>>> Thoughts
>>> 
>>> John B.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Openid-specs-native-apps mailing list
>>> Openid-specs-native-apps at lists.openid.net <mailto:Openid-specs-native-apps at lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps <http://lists.openid.net/mailman/listinfo/openid-specs-native-apps>
>> 
>> _______________________________________________
>> Openid-specs-native-apps mailing list
>> Openid-specs-native-apps at lists.openid.net <mailto:Openid-specs-native-apps at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps <http://lists.openid.net/mailman/listinfo/openid-specs-native-apps>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20141127/7472857e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20141127/7472857e/attachment-0001.p7s>