[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