Hi Rainer,
On 5 Jun 2019, at 8:09, Rainer Hoerbe wrote:
Hi,
To summarize:
- SATOSA_STATE in its original design is a straight link between SSO
request and response. After the frontend created the Response the
_save_state call will delete the cookie.
- To remember the selected IDP SATOSA_STATE across over the long term
state can be kept by setting CONTEXT_STATE_DELETE=False
I think that it could make sense to separate short- and long-running
state cookies. For my current use case (requiring a replay of the
previous AuthnRequest during Response processing in the backend) I
decided to create a separate cookie, which is in fact a key into a
local Redis store. It has a life cycle different, longer than a
straight Response, but not across SSO flows.
Yes, indeed. That was also my preferred approach, but then I realised
that we would need extra hooks to read the new cookies, which for #243
meant more and more changes. But yes a cookie like SSO_STATE would make
sense.
Scott has introduced another cookie, the common domain cookie in #172,
but at the moment this is only set by SATOSA it is not read/used by
SATOSA.
BTW, shouldn’t the proxy set HttpOnly and
SameSite=Strict for
SATOSA_STATE?
I believe that would make sense
Christos
Cheers, Rainer
> Am 2019-06-05 um 00:27 schrieb Christos Kanellopoulos
> <christos.kanellopoulos at geant.org>:
>
> Hello,
>
> for question (b) indeed there is a point to do that. If one wants to
> keep state across authentication requests, then SATOSA needs to
> search for the cookie also in the AuthN request and load the context
> if it is found and it is valid. For example, in PR #234 we add the
> option to save the selected IdP in the cookie so that in the follow
> up AuthN requests SATOSA can skip the discovery. Having said this,
> it’s been a year since I touched that code so Ivan please correct
> me if I am wrong.
>
> Christos
>
> From: Rainer Hoerbe <rainer at hoerbe.at>
> Sent: Friday, May 31, 2019 12:42 PM
> To: Ivan Kanakarakis; Christos Kanellopoulos
> Cc: satosa-dev at lists.sunet.se
> Subject: SATOSA_STATE
>
>
> I summarized the handling SATOSA_STATE as discussed in Tuesday’s
> meeting in the attached diagrams. I have two questions:
>
> a) Is this picture correct?
> b) Is there any purpose in loading the context from SATOSA_STATE when
> an AuthnRequest is received?
>
> Thanks, Rainer
>
>
>> Am 2019-05-30 um 13:09 schrieb Ivan Kanakarakis
>> <ivan.kanak at
gmail.com <mailto:ivan.kanak at gmail.com>>:
>>
>>
>> On Wed, 29 May 2019 at 23:28, Rainer Hoerbe <rainer at hoerbe.at
>> <mailto:rainer at hoerbe.at>> wrote:
>>
>>>
>>> Side topic: state/flow – need to discuss FE/BE state,
>>> long-running state (SATOSA is stateless). Shall we have policies
>>> around this? Need to describe use cases.
>>>
>>> Use case from Christos and Rainer require extra exchanges during
>>> the proxy flow, requiring to preserve state for the whole flow.
>>>
>>> Christos: Cookie deletion is removed with PR #234!
>>>
>>
>> It is now configurable ;)
>>
> <authnrequ_state.png><authnresp_state.png>
--
Christos Kanellopoulos
Senior Trust & Identity Manager
GÉANT
M: +31 611 477 919
Networks • Services • People
Learn more at
www.geant.org
GÉANT Vereniging (Association) is registered with the Chamber of
Commerce in Amsterdam with registration number 40535155 and operates in
the UK as a branch of GÉANT Vereniging. Registered office: Hoekenrode
3, 1102BR Amsterdam, The Netherlands. UK branch address: City House,
126-130 Hills Road, Cambridge CB2 1PQ, UK.