[Openid-specs-native-apps] Consent models (re: Minutes - March 19)

Paul Madsen paul.madsen at gmail.com
Tue Apr 8 20:14:59 UTC 2014


for comparison, John's proposed model

http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVCwgSVQALQcAXAYAMwVCb290c3RyYXAoQVQpCgB1BwAwBmJvbwAVBVVSTABmBgCBVQcAFQUALwYAFgUAgWwHAIEFBwAODgB-BQAvCXJlZGlyZWN0IHRvIEFTMihzY29wZSArIFNTTyB0b2tlbikAQQ0yOgCBTAV6cmVxdWVzdAApBisAIQxub3RlIG92ZXIgACkFdmFsaWRhdGUARwoKCkFTMgCBLwtjb25zZW4ARAcpPwBfEHllcwAiEHJldHVybiBub3RoaW5nAIFjC1RBOgANCQCDBAYyOiBleGNoYW5nZSBJVAB0BlRBOiBBAIJxB04ABgZOQS0-UlMyOiBSRVNUIGNhbGwgAIJ4BQoKCgoKAAEF&s=patent

On 4/8/14, 3:49 PM, John Bradley wrote:
> I was thinking of using the response_type=none for the outh flow to 
> AS2 simply to collect consent.
>
> The JWT or SAML assertion flow would be used to get the access token 
> from AS2.   The downside is that AS2 needs to support the assertion 
> flow but the upside is that AS1 has the ability to revoke access 
> without going thorough web redirects each time the AT needs to be 
> refreshed.
>
>
> On Apr 8, 2014, at 1:35 PM, Paul Madsen <paul.madsen at gmail.com 
> <mailto:paul.madsen at gmail.com>> wrote:
>
>> I think this wsd describes John's model
>>
>> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVAApBwBYBgAvBUJvb3RzdHJhcChBVCkKAHEHACwGYm9vABUFVVJMAGIGAIFRBwAVBQAvBgAWBQCBaAcAgQEHAA4OAHoFAC8JcmVkaXJlY3QgdG8gQVMyKHNjb3BlICsgU1NPIHRva2VuKQBBDTI6AIFIBXpyZXF1ZXN0ACkGKwAhDG5vdGUgb3ZlciAAKQV2YWx 
>> pZGF0ZQBHCgoKQVMyAIEvC2NvbnNlbgBEByk_AF8QeWVzACIQcmV0dXJuIGNvZGUgAIFhC1RBOgAPBQCCegcyOiBleGNoYW5nZQARBgByBVRBOiBhY2Nlc3MAgQYIVEEtPk4ABhBOQS0-UlM6IFJFU1QgY2FsbCAoACoMKQoKCgoKCgABBQ&s=patent
>>
>> Question - in the step that John refers to as 'trigger the IdP 
>> initiated login via Connect or SAML' - what support is there for an 
>> authenticated authz request?
>>
>> Distinct from how the browser gets sent to AS2 is what AS2 returns - 
>> in this case a code, and the TA exchanges that code for the desired 
>> AT ( to be handed to the native app)
>>
>> John was advocating a different model
>>
>> paul
>>
>> On 4/8/14, 2:46 PM, John Bradley wrote:
>>> For bootstrapping a web session in SAML as an example you could 
>>> directly create a IdP initiated login URI + post body and have the 
>>> browser send that to the third party AS directly.
>>> I think that is more problematic from a security perspective as 
>>> there is no way for the home AS to say compare the ip address of the 
>>> browser with the ip address of the TA or make use of other 
>>> authentication factors.
>>>
>>> Logically I prefer to have the TA bootstrap the browser to itself 
>>> and from there trigger the IdP initiated login via Connect or SAML. 
>>>   That is the only way you can do a IdP initiated login with 
>>> connect, otherwise the user needs to authenticate to there home AS 
>>> in the browser somewhat defeating the point.
>>>
>>>
>>> On Apr 8, 2014, at 12:36 PM, Paul Madsen <paul.madsen at gmail.com 
>>> <mailto:paul.madsen at gmail.com>> wrote:
>>>
>>>> hi Mike, inline
>>>>
>>>> paul
>>>>
>>>> On 4/7/14, 9:19 AM, Mike Varley wrote:
>>>>> A couple comments/questions:
>>>>> 1) what is the 'API' endpoint the bootstrap URL request is going 
>>>>> to? Is this the RS?
>>>> would be the AppInfo endpoint (hosted by AS1) that the NAPPS spec 
>>>> describes
>>>>
>>>> To obtain application metadata information, the /TA/ MAY make a GET 
>>>> or POST request to the AppInfo Endpoint.
>>>>
>>>>
>>>>> 2) Seems like a lot of round-trips. On mobile, performance will suffer
>>>> if the round trips are performed only for gathering consent ....
>>>>> 3) how does consent from the browser result in an AT to the App?
>>>>
>>>> John proposed a model where
>>>>
>>>> 1) the TA is delivered an id_token targeted at AS2
>>>> 2) the user agent is sent to AS2 for consent
>>>> 3) once consent is obtained, the TA exchanges the id_token for an AT
>>>> 4) TA hands AT to app
>>>>
>>>>>
>>>>> MV
>>>>>
>>>>> On Apr 4, 2014, at 5:53 PM, John Bradley <ve7jtb at ve7jtb.com 
>>>>> <mailto:ve7jtb at ve7jtb.com>> wrote:
>>>>>
>>>>>> If the target of the SAML IdP initiated login is the OAuth 
>>>>>> authorization Uri we shouldn't need extra attributes in the SAML 
>>>>>> assertion.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Apr 4, 2014, at 3:16 PM, Paul Madsen <paul.madsen at gmail.com 
>>>>>> <mailto:paul.madsen at gmail.com>> wrote:
>>>>>>
>>>>>>> I dont think we should preclude IdP-init SAML into the AS2 
>>>>>>> consent page - for those SaaS currently set up as SAML SPs & 
>>>>>>> OAuth AS
>>>>>>>
>>>>>>> implying us defining a scope param on the SAML Response?
>>>>>>>
>>>>>>>
>>>>>>> On 4/4/14, 2:16 PM, John Bradley wrote:
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>> There are two options I can think of for the last step of AS2 
>>>>>>>> collecting consent.
>>>>>>>>
>>>>>>>> The request can have a response_type of code and the TA gets 
>>>>>>>> back a code that it can use to get a AT from the AS2 token 
>>>>>>>> endpoint.
>>>>>>>>
>>>>>>>> The other would be to make the call to AS2 with a response-type 
>>>>>>>> of "none" just to collect consent, getting back nothing.
>>>>>>>> The TA would then use the JWT assertion flow to exchange a JWT 
>>>>>>>> for the access token.
>>>>>>>>
>>>>>>>> I think the second option is more secure and allows a JWT 
>>>>>>>> issued by AS1 to be used instead of a refresh token issued by 
>>>>>>>> AS2.  The advantage is that AS1 has the ability to revoke 
>>>>>>>> access to the resource without needing a separate API to AS2.
>>>>>>>>
>>>>>>>> John B.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Apr 4, 2014, at 2:00 PM, Paul Madsen <paul.madsen at gmail.com 
>>>>>>>> <mailto:paul.madsen at gmail.com>> wrote:
>>>>>>>>
>>>>>>>>> John, something like
>>>>>>>>>
>>>>>>>>> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDUFTMQACDlBJABEPMgoKClRBLT5BUzE6IGdldCB1c2VyIGF1dGhlbnRpY2F0ZWQKQVMxLT5UQTogUlQsQVQAKQdQSQArBUJvb3RzdHJhcChBVCkKQVBJACQGYm9vABEFVVJMAFoGAIEmBwAVBQArBgAWBQCBPQcAeQcADg4AcgUALwlyZWRpcmVjdCB0byBBUzIoaWRfdG9rZW4sc2NvcGUpAD4NMjoAgT0FenJlcXVlc3QAGhJub3RlIG92ZXIgACgFdmFsaWRhdGUgAE0ICgpBUzIAgSoLY29uc2VudCgAZgY_CgoKCgo&s=patent
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/4/14, 1:42 PM, John Bradley wrote:
>>>>>>>>>> I was thinking of a bootstrap URL that trigged idP initiated 
>>>>>>>>>> login at AS2.  That way the bootstrap URI is essentially 
>>>>>>>>>> opaque as it is both specified and consumed by the IsP/AS of 
>>>>>>>>>> the TA.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Apr 4, 2014, at 1:26 PM, Chuck Mortimore 
>>>>>>>>>> <cmortimore at salesforce.com 
>>>>>>>>>> <mailto:cmortimore at salesforce.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Sounds similar, yes, although working out a boostrap URL 
>>>>>>>>>>> across different ASs might be quite difficult in practice
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 4, 2014 at 10:25 AM, Paul Madsen 
>>>>>>>>>>> <paul.madsen at gmail.com <mailto:paul.madsen at gmail.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>     hey Chuck, you write
>>>>>>>>>>>
>>>>>>>>>>>     'If the TA were to simply use it's primary token to
>>>>>>>>>>>     initialize an OAuth authorization request for the scope
>>>>>>>>>>>     of the requesting native app, we could simplify this
>>>>>>>>>>>     whole thing.  '
>>>>>>>>>>>
>>>>>>>>>>>     John had (in this thread) previously proposed something
>>>>>>>>>>>     similar
>>>>>>>>>>>
>>>>>>>>>>>     'If we have a web app bootstrap AS1 could give a
>>>>>>>>>>>     bootstrap URI to the App that would create a
>>>>>>>>>>>     authenticated session at AS2 for the user to do the
>>>>>>>>>>>     normal OAuth consent flow.'
>>>>>>>>>>>
>>>>>>>>>>>     I believe John's model accomplishes the same thing as
>>>>>>>>>>>     your proposal, ie delivers the user's browser (in an
>>>>>>>>>>>     authenticated state) to an AS where consent can be
>>>>>>>>>>>     gathered - albeit perhaps with more steps
>>>>>>>>>>>
>>>>>>>>>>>     paul
>>>>>>>>>>>
>>>>>>>>>>>     On 4/2/14, 5:49 PM, Chuck Mortimore wrote:
>>>>>>>>>>>>     We don't think there should at all be an "implied
>>>>>>>>>>>>     consent" model (i.e., authentication at the AS
>>>>>>>>>>>>     authorizes the App for whatever it needs).  This sound
>>>>>>>>>>>>     quite dangerous, and don't believe this would at all be
>>>>>>>>>>>>     suitable for a tightly controlled enterprise
>>>>>>>>>>>>     environment.  We do support models that "feel" like
>>>>>>>>>>>>     this, but consent really isn't implicit...It's simply
>>>>>>>>>>>>     isn't controlled or visilbe to the the user.   We
>>>>>>>>>>>>     always run the request through an authorization check,
>>>>>>>>>>>>     and it is not at all coupled to authentication.  
>>>>>>>>>>>>     Picture us checking a role on the AS.
>>>>>>>>>>>>
>>>>>>>>>>>>     As far JIT consent model, it's a bit harder to achieve
>>>>>>>>>>>>     when using the Token Endpoint, unless we explicitly
>>>>>>>>>>>>     specify the TA is collecting consent, what to collect,
>>>>>>>>>>>>     etc.  Standardizing a consent UI strikes me as very
>>>>>>>>>>>>     difficult.
>>>>>>>>>>>>
>>>>>>>>>>>>     The way we've balanced the two in our environment is to
>>>>>>>>>>>>     always perform consent on the authorization endpoint.
>>>>>>>>>>>>     Based on the configuration of the app, we're either
>>>>>>>>>>>>     checking server side admin defined consent, or
>>>>>>>>>>>>     prompting the user.
>>>>>>>>>>>>
>>>>>>>>>>>>     It's possible we could continue to use this model in
>>>>>>>>>>>>     NAPPS - if we consider the real difficult issue for
>>>>>>>>>>>>     users is actually authenticating, then authorization is
>>>>>>>>>>>>     really not a big deal. If the TA were to simply use
>>>>>>>>>>>>     it's primary token to initialize an OAuth authorization
>>>>>>>>>>>>     request for the scope of the requesting native app, we
>>>>>>>>>>>>     could simplify this whole thing.
>>>>>>>>>>>>
>>>>>>>>>>>>     -cmort
>>>>>>>>>>>>
>>>>>>>>>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140408/ff6d4bd7/attachment-0001.html>


More information about the Openid-specs-native-apps mailing list