Hi folks,
I'm wondering to develop a microservice on top of asyncio for manage
multiple connections to many LDAP servers (or any kind).
I think that this would be the best solution for a performant, flexible and
highly customizable account linking.
What do you think?
https://docs.python.org/3/library/asyncio.html
--
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
If would like to discuss a logging feature that I would like to see in Satosa. I proposed with PR 237 to add a log filter that would enhance satosa's logging capabilities. Ivan rejected it for the (in general good) reason that the proxy should log everything and log processing should be external.
I agree in general, but there are bits where I still think that they would be useful in satosa. These are:
1. In production environments it is unlikely to push the full set of debug information to a logging service. However, it might be useful to get debug level data on certain selections. Usually that would be based in IP addresses, which should not be too complicated to implement.
2. In a dev environment one is easily inundated with debug data. Shibboleth has a nice feature providing logging levels for certain aspects, such as XML tooling, SAMl message de-/encoding. I find this capability quite useful, because in my dev environment I do not have an elaborate log processor. Attribute configuration in satosa could be helped by selected messages.
If done properly, this change has following impact on all modules that instantiate a logger:
1. refactor the satosa_logger wrapper back to the native logger with similar signature
2. add a log filter after each get_logger()
The logfilter (logging.Filter) is orthogonal to structured logging, or may even help to improve it.
see: https://github.com/IdentityPython/SATOSA/pull/237 <https://github.com/IdentityPython/SATOSA/pull/237>
Cheers, Rainer
Hi,
As already mentioned to Ivan during our previous meeting I do not use
docker but a bootstrap procedure on top of virtualenv.
In production I use uwsgi instead of gunicorn. A configuration example Is
here:
https://github.com/peppelinux/Satosa-saml2saml/tree/master/example/uwsgi_se…
If It could be usefull to the community we could serve this examples
directly into SATOSA. With uwsgi I have a lot of professional features like
http statistics server in json format, triggers that reload workers on file
change (or simply touch) and many others that Is not yet included there.
I share as It come, if usefull I can do a style and comments clean up
--
------------------------------------------------------------------------------------------------------------------
Il banner è generato automaticamente dal servizio di posta elettronica
dell'Università della Calabria
<http://www.unical.it/5x1000>
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>
On Fri, 31 May 2019 at 12:37, Rainer Hoerbe <rainer at hoerbe.at> wrote:
>
> 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?
Looks right to me. btw, I think those diagrams are really helpful,
thanks for making them ;)
>
> b) Is there any purpose in loading the context from SATOSA_STATE when an AuthnRequest is received?
>
In general, no; it is there as part of the generic process (it does
not specialize for the authn-request flow).
But, one can use this to make some special things happen, ie use the
cookie for feature flags.
--
Ivan c00kiemon5ter Kanakarakis >:3
Hi,
I require the SATOSA SAMLFrontend to assert the following XML for
eduPersonTargetedID as part of an <AttributeStatement>
<Attribute FriendlyName="eduPersonTargetedID"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<AttributeValue>
<NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="https://proxy.my.org/idp/satosa"
SPNameQualifier="https://service.my.org/sp/shibboleth">
1088878806
</NameID>
</AttributeValue>
</Attribute>
Here the value 1088878806 for <NameID> is to be taken from a database (I will
be using an LDAP directory, but in general it is being pulled from some
storage), the NameQualifier is the entityID for the SATOSA proxy IdP frontend
(the SAMLFrontend instance), and the SPNameQualifier is the entityID for the SP
that sent the <AuthnRequest> to the SATOSA proxy IdP frontend.
Has anybody configured the existing SATOSA and pysaml2 code to assert such
XML? If so can you share some details of your configuration?
If not, is anybody using modified SATOSA or pysaml2 code that has not been
contributed yet to assert such XML and is willing to share and/or collaborate
on getting it contributed (relatively quickly)?
Thanks,
Scott K
P.S. I am fully aware that there are reasons to deprecate the use of
eduPersonTargetedID. For this particular deployment I need to assert this
attribute for the time being using SATOSA.
Hi,
Am I correct that the SATOSA SAMLBackend class currently has no way to
dynamically set "force_authn" so that the SAML authn request sent to the
authenticating (campus) IdP includes the forced reauthentication flag?
Thanks,
Scott K
