Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response
Am 16.06.2010 00:35, schrieb Brian Eaton: On Tue, Jun 15, 2010 at 8:54 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Wouldn't it be an alternative solution, if the AS first tries to authenticate the user using SPNEGO within the Web Server flow? This should work in the inhouse scenario. If it fails, it can fall back to username/password auth.. This would let you skip password entry, but I think you'd still require user confirmation to grant the access. which is ok, if you want to involve the user in the process. So he/her realizes what's going on. Otherwise, the assertion workflow would be the better choice. regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response
+1 On 2010-06-14, at 9:02 PM, Brian Eaton wrote: On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott andrewarn...@gmail.com wrote: For an application I'm building, the installed client app will have intermittent windows of time where it can obtain a (non-OAuth) assertion for user identity. During this time, it seems appropriate for it to use the assertion flow to obtain an OAuth authorization so that it can impersonate the user. So far this is just standard Assertion Flow stuff. But without a refresh_token, the app will break when the access token expires if the app doesn't have the ability at the moment (due to not being on the corporate network at the moment for example) to obtain a new assertion. Since the security model for this app would certainly allow for a refresh_token to be issued from the original OAuth authorization server exchange, this would solve it, if the spec didn't specifically ban such a parameter. I think this is a different use case than the one envisioned by most people who are using the assertion flow. I'm inclined to steer different use cases to different profiles. It makes it much easier to guide deployments, for example. Cheers, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response
In this case, the assertion the client starts with is from Windows authentication, and the assertion is obtained from an Active Directory server that is inaccessible unless the client app is running on a computer currently connected to the corporate network. I imagine that assertion has a limited lifetime, and the client doesn't have access to it anyway since it is added to the HTTP request by the platform, and is a challenge-response based protocol and therefore cannot be replayed later. So sure, I can read SHOULD NOT as a recommendation and do it anyway (using the standard parameter name refresh_token). The assertion itself being a challenge-response type thing in the transport itself, this profile seems to apply even less unless it can be worded to say the assertion can be found elsewhere. (there's precedence for this in the spec that talks about how client credentials can be found in any of multiple places but must only be found in ONE of them). Let me know what you think. If I need to invent my own profile I guess I can do that. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - S. G. Tallentyre On Mon, Jun 14, 2010 at 8:50 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: First, the spec says “SHOULD NOT issue a refresh token” which means, don’t do it unless you have to. But what stops the client from keeping the same assertion and reusing it later? As for using other methods for providing an assertion, you need to be more specific about what you have in mind. But either way, you can extend the token endpoint to support other ways of providing assertions. EHL *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Andrew Arnott *Sent:* Monday, June 14, 2010 8:32 PM *To:* OAuth WG (oauth@ietf.org) *Subject:* [OAUTH-WG] Assertion flow: please add optional refresh_token in response For an application I'm building, the installed client app will have intermittent windows of time where it can obtain a (non-OAuth) assertion for user identity. During this time, it seems appropriate for it to use the assertion flow to obtain an OAuth authorization so that it can impersonate the user. So far this is just standard Assertion Flow stuff. But without a refresh_token, the app will break when the access token expires if the app doesn't have the ability at the moment (due to not being on the corporate network at the moment for example) to obtain a new assertion. Since the security model for this app would certainly allow for a refresh_token to be issued from the original OAuth authorization server exchange, this would solve it, if the spec didn't specifically ban such a parameter. Also, the user identity is asserted to the authorization server *not*through an *assertion* parameter but using Kerberos (I assume) as part of the HTTP protocol, so perhaps the spec for the assertion flow can specifically allow for assertions to be carried as part of the transport? -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - S. G. Tallentyre ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response
Why can the client app access the AS to get an access token but not the corporate network to get a new assertion? How does the client app get the assertion to begin with? How did delegation from the user happen? Would you elaborate more on the use case so that we can understand the full trust model? The assertion flow was intended for autonomous clients rather than user delegation -- hence Brian's response and mine that this is a different flow if the access token is for user delegation. -- Dick On 2010-06-15, at 6:58 AM, Andrew Arnott wrote: Well it's easy enough for me to just make up a profile that follows rules I set. But since I don't think this need will be unique to myself, would you like me to write up a spec somewhere? (I've never written an IETF spec before) -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - S. G. Tallentyre On Mon, Jun 14, 2010 at 11:00 PM, Dick Hardt dick.ha...@gmail.com wrote: +1 On 2010-06-14, at 9:02 PM, Brian Eaton wrote: On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott andrewarn...@gmail.com wrote: For an application I'm building, the installed client app will have intermittent windows of time where it can obtain a (non-OAuth) assertion for user identity. During this time, it seems appropriate for it to use the assertion flow to obtain an OAuth authorization so that it can impersonate the user. So far this is just standard Assertion Flow stuff. But without a refresh_token, the app will break when the access token expires if the app doesn't have the ability at the moment (due to not being on the corporate network at the moment for example) to obtain a new assertion. Since the security model for this app would certainly allow for a refresh_token to be issued from the original OAuth authorization server exchange, this would solve it, if the spec didn't specifically ban such a parameter. I think this is a different use case than the one envisioned by most people who are using the assertion flow. I'm inclined to steer different use cases to different profiles. It makes it much easier to guide deployments, for example. Cheers, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response
Are you envisioning the client makes a call to AD to get an assertion where the call is automagically authenticated as the user by NTLM? What do you envision being the relationship between the AS and AD? What authority does the AS have? How long is the refresh token valid for? I think you have an interesting use case here, but it would be useful to step back and describe how the client got to the point you are envisioning per my last email. -- Dick On 2010-06-15, at 7:03 AM, Andrew Arnott wrote: In this case, the assertion the client starts with is from Windows authentication, and the assertion is obtained from an Active Directory server that is inaccessible unless the client app is running on a computer currently connected to the corporate network. I imagine that assertion has a limited lifetime, and the client doesn't have access to it anyway since it is added to the HTTP request by the platform, and is a challenge-response based protocol and therefore cannot be replayed later. So sure, I can read SHOULD NOT as a recommendation and do it anyway (using the standard parameter name refresh_token). The assertion itself being a challenge-response type thing in the transport itself, this profile seems to apply even less unless it can be worded to say the assertion can be found elsewhere. (there's precedence for this in the spec that talks about how client credentials can be found in any of multiple places but must only be found in ONE of them). Let me know what you think. If I need to invent my own profile I guess I can do that. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - S. G. Tallentyre On Mon, Jun 14, 2010 at 8:50 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: First, the spec says “SHOULD NOT issue a refresh token” which means, don’t do it unless you have to. But what stops the client from keeping the same assertion and reusing it later? As for using other methods for providing an assertion, you need to be more specific about what you have in mind. But either way, you can extend the token endpoint to support other ways of providing assertions. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Andrew Arnott Sent: Monday, June 14, 2010 8:32 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Assertion flow: please add optional refresh_token in response For an application I'm building, the installed client app will have intermittent windows of time where it can obtain a (non-OAuth) assertion for user identity. During this time, it seems appropriate for it to use the assertion flow to obtain an OAuth authorization so that it can impersonate the user. So far this is just standard Assertion Flow stuff. But without a refresh_token, the app will break when the access token expires if the app doesn't have the ability at the moment (due to not being on the corporate network at the moment for example) to obtain a new assertion. Since the security model for this app would certainly allow for a refresh_token to be issued from the original OAuth authorization server exchange, this would solve it, if the spec didn't specifically ban such a parameter. Also, the user identity is asserted to the authorization server not through an assertion parameter but using Kerberos (I assume) as part of the HTTP protocol, so perhaps the spec for the assertion flow can specifically allow for assertions to be carried as part of the transport? -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - S. G. Tallentyre ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response
Hi Dick, Responses inline. On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt dick.ha...@gmail.com wrote: Why can the client app access the AS to get an access token but not the corporate network to get a new assertion? The corporate network where the AD lives is behind a firewall, whereas the AS is on the public Internet. So when the client is on the public Internet, the AD is not available but the AS is. Also, the resource server is on the public Internet (probably obvious). How does the client app get the assertion to begin with? How did delegation from the user happen? There are two possible scenarios here, which I will outline and inject the steps in each scenario: 1. The client app is initially launched while on the corporate network 1. The client sends an HTTP request to *an *endpoint on a *corpnet *AS(1) (directly -- not through a browser), which sniffs the request for NTLM credentials (or however Windows auth does it) and if present immediately responds with an authorization code (a.k.a. verification code) rather than prompting the user for permission. This is considered reasonable in this application because the client is already running on a trusted machine and the privacy ramifications are minimal. 2. The client app exchanges the authorization code for a refresh token and an access token at the AS(2) token endpoint, which lies outside the corporate firewall, and can thereby refresh access tokens when the client is off corpnet. 3. All resource requests use an OAuth access token to gain access. 2. The client app is initially launched *off* the corporate network. 1. This just uses the standard user agent or web server flows, including prompting the user for authorization. Would you elaborate more on the use case so that we can understand the full trust model? Perhaps my description above covers this question. I'll just add that the goal is to make the authorization process as painless (or altogether absent from the user's point of view) as possible. We're also considering providing customized app downloads to each user based on the Windows auth user that downloads the .zip file, such that the client app includes a file containing the authorization code encoded for that particular user. The assertion flow was intended for autonomous clients rather than user delegation -- hence Brian's response and mine that this is a different flow if the access token is for user delegation. That makes sense. Are you envisioning the client makes a call to AD to get an assertion where the call is automagically authenticated as the user by NTLM? Perhaps my scenarios above clarified this. My client never explicitly calls AD though. Whether that happens implicitly by the Windows platform, I don't know. What do you envision being the relationship between the AS and AD? What authority does the AS have? How long is the refresh token valid for? The refresh token would be valid until the user logged into the AS (or RS perhaps) to revoke it. The AD is altogether unaware of the AS, but the AS trusts the AD to have authenticated the user and trusts the AD assertion. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response
Wouldn't it be an alternative solution, if the AS first tries to authenticate the user using SPNEGO within the Web Server flow? This should work in the inhouse scenario. If it fails, it can fall back to username/password auth.. Thoughts? regards, Torsten. Am 15.06.2010 um 17:19 schrieb Andrew Arnott andrewarn...@gmail.com: Hi Dick, Responses inline. On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt dick.ha...@gmail.com wrote: Why can the client app access the AS to get an access token but not the corporate network to get a new assertion? The corporate network where the AD lives is behind a firewall, whereas the AS is on the public Internet. So when the client is on the public Internet, the AD is not available but the AS is. Also, the resource server is on the public Internet (probably obvious). How does the client app get the assertion to begin with? How did delegation from the user happen? There are two possible scenarios here, which I will outline and inject the steps in each scenario: The client app is initially launched while on the corporate network The client sends an HTTP request to an endpoint on a corpnet AS(1) (directly -- not through a browser), which sniffs the request for NTLM credentials (or however Windows auth does it) and if present immediately responds with an authorization code (a.k.a. verification code) rather than prompting the user for permission. This is considered reasonable in this application because the client is already running on a trusted machine and the privacy ramifications are minimal. The client app exchanges the authorization code for a refresh token and an access token at the AS(2) token endpoint, which lies outside the corporate firewall, and can thereby refresh access tokens when the client is off corpnet. All resource requests use an OAuth access token to gain access. The client app is initially launched off the corporate network. This just uses the standard user agent or web server flows, including prompting the user for authorization. Would you elaborate more on the use case so that we can understand the full trust model? Perhaps my description above covers this question. I'll just add that the goal is to make the authorization process as painless (or altogether absent from the user's point of view) as possible. We're also considering providing customized app downloads to each user based on the Windows auth user that downloads the .zip file, such that the client app includes a file containing the authorization code encoded for that particular user. The assertion flow was intended for autonomous clients rather than user delegation -- hence Brian's response and mine that this is a different flow if the access token is for user delegation. That makes sense. Are you envisioning the client makes a call to AD to get an assertion where the call is automagically authenticated as the user by NTLM? Perhaps my scenarios above clarified this. My client never explicitly calls AD though. Whether that happens implicitly by the Windows platform, I don't know. What do you envision being the relationship between the AS and AD? What authority does the AS have? How long is the refresh token valid for? The refresh token would be valid until the user logged into the AS (or RS perhaps) to revoke it. The AD is altogether unaware of the AS, but the AS trusts the AD to have authenticated the user and trusts the AD assertion. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response
On Tue, Jun 15, 2010 at 8:54 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Wouldn't it be an alternative solution, if the AS first tries to authenticate the user using SPNEGO within the Web Server flow? This should work in the inhouse scenario. If it fails, it can fall back to username/password auth.. This would let you skip password entry, but I think you'd still require user confirmation to grant the access. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
