Am 16.06.2010 00:35, schrieb Brian Eaton:
On Tue, Jun 15, 2010 at 8:54 AM, Torsten Lodderstedt
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 c
On Tue, Jun 15, 2010 at 8:54 AM, Torsten Lodderstedt
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..
T
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
To me, the use case described is more similar to the "Username and
Password flow" but where the user credentials are NOT username &
password. Should we have two "user credential" flows? (1) Username and
Password and (2) assertion/token? I can see it being useful to have a
"user credential" flow
Hi Dick,
Responses inline.
On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt 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 I
> 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
>
>
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
[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, th
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
+1
On 2010-06-14, at 9:02 PM, Brian Eaton wrote:
> On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott 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
On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott 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
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 flo
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 us
13 matches
Mail list logo
