Hello all,
Across the satosa codebase there are places where a default behaviour
is needed. There are two ways we signify this:
- Using the empty string as a dictionary key
- Using the string "default" as a dictionary key
(where other keys define behaviour/settings for specific entities.)
I am not sure how the project ended up with two ways to signify a
default set, but it is annoying.
In terms of the chosen strings to represent the default set, "" seems
to be a valid choice, as no entity (usually entityid) should be empty.
"default" on the other hand, is more descriptive and self documenting,
and hopefully nobody uses that to describe and entity (or as an
entityid).
In terms of handling this, there is currently a function under
`src/satosa/util.py` namely `get_dict_defaults()` that favours "" over
"default" – it fallbacks to "default" if "" is not set. While this is
fine and works, it is not used across the codebase.
I would like this to be resolved and have a single way to signify a
default behaviour.
What are your opinions? Do you think this should settle to a single
way of representing a default set, even if that means that people
using "" or "default" will have to migrate (this would be a breaking
change for their configs)? Which is the most appropriate way to go?
Cheers,
PS: This discussion was triggered by skoranda's PR here:
https://github.com/IdentityPython/satosa_microservices/pull/6/files#r148260…
--
Ivan c00kiemon5ter Kanakarakis >:3
Hi,
The Shibboleth IdP has the nice feature [1] that it can be configured to set
the IdP Discovery Profile common domain cookie [2] after receiving a
valid assertion from an IdP. It can be useful because only IdPs that a
user has actually successfully used are recorded and then later revealed
as choices to the user in a subsequent flow.
I have a use case where it would be helpful if the SP side of SATOSA
could do the same thing.
I ran
find . -type f -exec grep -l _saml_idp {} \;
on the SATOSA source and it did not return anything, so I suspect this
functionality is not currently supported by SATOSA.
Would anybody object to adding it? It would of course be "off" by
default and would only set the cookie (with configurable properties)
when configured to do so.
Thoughts?
Thanks,
Scott K
P.S. I understand that new approaches to discovery that will likely come
out of the RA21 effort will probably supplant this functionality, but as
usual the use case I need to support needs this "right now"...
[1] See idpHistory and idpHistoryProps at
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions
[2] See section 4.3 of
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
Dear all,
I am pleased to announce that Heather Flanagan [1] has been funded by
the National Institute of Health's National Institute of Allergies and
Infectious Diseases (NIH NIAID) to act as the project manager for the
Identity Python project. This represents a major step for the project
and will enable us to move forward more quickly and will also help us
establish the Identity Python governance and organizational structure
needed for long-term sustainability of the project.
[1] https://www.linkedin.com/in/hlflanagan/
Cheers Leif
Folks,
I'm thinking it might be a good idea to have a dev meeting
soon to discuss progress and some of the recent development
efforts that have been very active recently.
Who would be interested in (and able to) come to Stockholm
for a (say) 2 day workshop sometime in the Oct-Nov-Dec
time frame (when Sweden really shines as a warm and sunny
place you really want to travel to) ?
Cheers Leif
Hello,
Just to inform you I have just transfered SATOSA from SUNET to
IdentityPython on github.
Br
--
Johan Lundberg
SUNET
Tulegatan 11
113 53 Stockholm
+46730714375
Actually it is a little late. Anytime after 6 am Chicago time works for me.
Thanks,
Scott
On Oct 12, 2017 3:56 AM, "Roland Hedberg" <roland at catalogix.se> wrote:
> Works for me.
>
> So, 6-7pm CEST ? Or is that to early for you Scott ?
>
> > 12 okt. 2017 kl. 10:52 skrev Leif Johansson <leifj at sunet.se>:
> >
> > On 2017-10-12 10:43, Scott Koranda wrote:
> >>> Looking at calendars I don't believe we can pull this together
> >>> sufficiently soon for it to make sense to have a dev meeting
> >>> before TIIME.
> >>>
> >>> So I think we should just talk to Rainer, reserve a full day
> >>> of work at TIIME and maybe try to have a couple of VCs (maybe
> >>> even a regular bi-weekly project call) until then.
> >>>
> >>> What say you all?
> >>
> >> I think that will work.
> >>
> >> When should the VCs start? I propose we aim for the week of October 30.
> >>
> >> To help organize an agenda, I also propose we start using the GitHub
> >> wiki for SATOSA at
> >>
> >> https://github.com/SUNET/SATOSA/wiki
> >>
> >> Thoughts?
> >
> > Yeah that works. How about 25:th ?
> >
> > _______________________________________________
> > Satosa-dev mailing list
> > Satosa-dev at lists.sunet.se
> > https://lists.sunet.se/listinfo/satosa-dev
>
> -- Roland
> "Education is the path from cocky ignorance to miserable uncertainty.” -
> Mark Twain
>
>
>
>
The SAML backend breaks on loading metadata from a URL if it contains non-ASCII characters (https://github.com/rohe/pysaml2/issues/463) After analyzing the cause I found that this has already been fixed in pysaml2 since 4.4.0.
My preferred option would be to nudge pysaml2 maintainers to release a new pypi version. It could save other developers from hunting bugs that have been fixed. If that is not feasible, the docker installation option should be changed to install the current version from github.
Cheers, Rainer
Hi,
I just created 3 pull requests in the new microservices repository that
add functionality to the LDAP attribute store:
1) Ignore an SP if so configured so that no attempt to lookup attributes
in the LDAP will be attempted. This is useful in particular when a
COmanage SP is behind the proxy and you want to just pass through the
attributes asserted by the IdP (or perhaps manage them with other
microservices first but not look up the user in LDAP).
2) The refactoring of how attributes asserted by the IdP are processed
to find the "primary identifier" that is then used to lookup the user in
LDAP. This is a breaking change in configuration syntax that I mentioned
earlier.
3) The ability to redirect to a configured URL if no record is returned
from LDAP. This is useful if the user has not enrolled in a VO and you
want to forward to an enrollment page or the like.
Also, a "heads up" that I am beginning another enhancement.
I did the "easy thing" first with LDAP, so the code right now opens a
connection, binds, does the search(es), then unbinds for each trip
through the proxy. Doing so is not, of course, optimal from the
performance perspective.
So I am evolving the code so that connection pools will be set up, one
for each LDAP server, when the proxy starts up and during a trip through
the proxy an existing connection should be used. In my early testing
this decreased the amount of time spent at the proxy by a factor of 5,
but of course the network "distance" between the proxy and LDAP affects
that and I am testing with the proxy local and the LDAP server not
local, so I do not expect such a large gain in production, but it should
be noticeably faster for the user.
If you have any questions or concerns about the LDAP attribute store
please let me know.
Thanks,
Scott K
Hi,
I am wondering if a separate repository for SATOSA plugins and/or
microservices has been set up yet?
I have some updates for the LDAP attribute store microservice that I have been
waitint to push until it is moved to a different repository.
Should I continue to wait or just go ahead and push the changes (or more
precisley submit a pull request)?
Thanks,
Scott K
