Hi,
On the last DEV call we talked about moving to using type hints.
The typing module was added in Python 3.5, but as of today SATOSA still
supports Python 3.4.
I apologize if I missed it, but did we discuss stopping support for
Python 3.4? If so, when?
Thanks,
Scott
Hi,
I have a response microservice that needs some information that only the
frontend knows.
>From what I can tell, there is no way for the microservice to get a hook
into the frontend in order to gather the information.
Am I missing something?
Thanks,
Scott K
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.
BTW, shouldn’t the proxy set HttpOnly and SameSite=Strict for SATOSA_STATE?
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>
