Hello,
We are using SATOSA primarily as a SAML-to-SAML proxy. One of the IdPs
that federated with the proxy requires signed authn requests. I do not
see that the current verion of SATOSA allows one to configure that
authn requests sent to a particular IdP are signed. Please let me know
if I am incorrect.
The underlying pysaml2 library, of course, does support sending a signed
authn request. It also supports the option "authn_requests_signed":
"Indicates if the Authentication Requests sent by this SP should be
signed by default. This can be overriden by application code for a
specific call."
I suspect SATOSA would pass through the authn_requests_signed option to
pysaml2 already, but I am more interested in being able to control
signing on a per-IdP basis, rather than making it the default for all
IdPs.
Patching SATOSA so that one could configure signing for particular IdPs
looks straightforward. I suspect the largest issue would be the
configuration (yaml) syntax.
My proposal is that saml2_backend.yaml look like this for such a scenario
(leaving out the other options and boilerplate):
module:
satosa.backends.saml2.SAMLBackend
name:
Saml2
config:
sp_config:
service:
sp:
relying_parties:
https://some.idp/entityid:
authn_requests_signed: True
https://another.idp/entityid:
authn_requests_signed: True
This format would be easy to extend over time to enable per-relying party
overrides for the options that pysaml2 allows to be configured per flow.
Thoughts?
Thanks,
Scott K
Hello,
Does SATOSA currently have a URL endpoint that is "satisfactory" and
"clean" for a service health check when running the service behind a
load balancer like Amazon ELB?
I am thinking of something like
https://proxy.my.org/status
If it does not exist already, I propose such an endpoint be added.
Initially all it needs to do is reply with '200 OK' to indicate that the
service is alive. Eventually as time and needs permits it could be
evolved to do something more sophisticated.
Thoughts?
I will open a GitHub issue if nobody objects or tells me that this
functionality already exists.
Thanks,
Scott K
On 2017-02-23 17:40, Niels van Dijk wrote:
> Hi
>
> I think in principle we have the/a correct way of dealing with this in
> the deployment of eduTEAMS Identity Hub already: its ansible deployment
> scripts pull from specific repositories 3 kinds of content: (1) core
> satosa, (2) consent servcie, (3) account linking service, all with
> specific versions and adds platform specific configuration to that mix
> to create the service. See the TEIPdeploy repo for an example:
> https://dev.niif.hu/vopaas/TEIP-deploy/blob/master/playbook/teipservers.yml.
> I have already had scenario of dealing with new versions of satosa and
> the other microservices coming into the depoy as Rebecka made changes to
> them based on our requirements and also because of bugs. This worked
> just fine, as long as Rebecka told me what new configurational settings
> to adopt. In the somewhat longer run I would prefer e.g. Stavros to also
> take care of the Ansible deployment scripts as he will be much closer to
> the actual software. One missing piece is by the way still that some
> gui is not really externally configurable in SatoSa, which is something
> we would want to address.
>
> For InAcademia this is a different case as here Leifs scripst are
> handling the deployment, and also the InAcademia deployement is much
> more complex because it has a distributed setup. As discussed earlier in
> the InAcademia meeting, we should set up a f2f meeting/workshop to get
> Leif, Stavros, Ioannis and maybe also me synced on how that works.
>
So I think ansible and puppet deserve their own special repos -
otherwize I suspect it becomes to hard to consume them into
puppet ansible who both expect to have plugins as separate things
in git etc right?
Cheers Leif
> Cheers,
>
> Niels
>
>
> On 23-02-17 16:21, Ioannis Kakavas wrote:
>> Sorry for the double mail, getting a bit mentally exhausted after
>> TIIME. We should probably figure out a way to differentiate
>> discussions/feedback etc between satosa as a project and products that
>> use satosa (inAcademia).
>>
>> This discussion for example started from a request that Lukas made for
>> inAcademia and the UI changes (colors etc)are specific to inAcademia
>> so its probably not very relevant for satosa-dev.
>>
>> Maybe what could be of interest for that list/community would be a
>> discuss on how to make the UI of the consent module based on ie
>> Bootstrap and make it easy to have "themes" (inAcademia theme, etc) .
>> I will create an enhancement issue on github once the consent module
>> has been moved to satosa-contrib and we can discuss if it's worth
>> looking into it.
>>
>>
>> Best
>> Ioannis
>>
>> Sent from BlueMail <http://www.bluemail.me/r?b=8872>
>> ------------------------------------------------------------------------
>> *From:* Ioannis Kakavas
>> *Sent:* Thu Feb 23 16:05:42 GMT+01:00 2017
>> *To:* Stavros 0 Sachtouris
>> *Cc:* Niels van Dijk , "Lukas Hämmerle"
>> *Subject:* Re: First SaToSa change
>>
>> The idea is to move all related software (microservices mostly) to a
>> satosa-contrib repository so that will mitigate that concern.
>>
>> Ioannis
>>
>> Sent from BlueMail <http://www.bluemail.me/r?b=8872>
>> ------------------------------------------------------------------------
>> *From:* Stavros 0 Sachtouris
>> *Sent:* Thu Feb 23 14:32:48 GMT+01:00 2017
>> *To:* Niels van Dijk , "Lukas Hämmerle" , Ioannis Kakavas
>> *Subject:* Re: First SaToSa change
>>
>> Hi Niels,
>>
>> in this particular case, the consent module is not a part of the
>> SAtoSA github repository. My concern is that, if people follow the
>> SAtoSA repository, will they be notified about changes happening in
>> other related repositories if they are not notified through the list?
>>
>> Stavros
>>
>> On 02/23/2017 11:50 AM, Niels van Dijk wrote:
>>> Hi Stavros,
>>>
>>> Yesterday at the TIIME meeting we have a meeting with various teams that
>>> work with SaToSa (SUnet, GEANT, SCG). We agreed that the satosa github
>>> issues tracker for requesting feedback, putting in new feature requests,
>>> and that pull requests is indeed the right way to go as well for
>>> proposing software changes.
>>>
>>> Cheers,
>>>
>>> Niels
>>>
>>>
>>> On 23-02-17 10:33, Stavros 0 Sachtouris wrote:
>>>> Hi Lukas,
>>>>
>>>> thank you for the feedback, I will drop the pull request and update
>>>> the patch with those of your observations that are not subject of
>>>> further discussion.
>>>>
>>>> Just one question: what is the right list to ask for feedback?
>>>>
>>>> Stavros
>>>>
>>>> On 02/23/2017 09:49 AM, Lukas Hämmerle wrote:
>>>>> Hi Stavros
>>>>>
>>>>> Great, this looks already a lot better than the current consent screen :-)
>>>>>
>>>>> A few quic comments/suggestions:
>>>>> * In the mobile version, the language selection is a bit too close to
>>>>> the InAcademia logo. Some space could help there. Even better, like in
>>>>> the desktop version you might want to reduce the width of the drop-down
>>>>> list as its (short) content is in no relation to its with currently.
>>>>> * typo: "Click to see what else is sent with your consent" (you instead
>>>>> of your)
>>>>> * Personally, for InAcademia I would not leave the user the confusing
>>>>> option to define for how long the consent should be given. Instead I
>>>>> would just set a default of 3 months and add a note "Your consent
>>>>> decision is stored for 3 months" but that isYesterday at the TIIME meeting we have a meeting with various teams that
>>>>> work with SaToSa (SUnet, GEANT, SCG). We agreed that the satosa github
>>>>> issues tracker for requesting feedback, putting in new feature requests,
>>>>> and that pull requests is indeed the right way to go as well for
>>>>> proposing software changes. probably something to discuss
>>>>> * I would use the same font size for the attribute name and value. Too
>>>>> many font-sizes are confusing.
>>>>> * Instead of:
>>>>> ----------------------------------------------------------------
>>>>> Given name
>>>>> ✓ ['Stavros']
>>>>> ----------------------------------------------------------------
>>>>> How about much simpler and space-saving
>>>>> ----------------------------------------------------------------
>>>>> Given name Stavros
>>>>> ----------------------------------------------------------------
>>>>> * Personally I would switch the positions of the OK and No buttons and
>>>>> align them right.
>>>>>
>>>>>
>>>>> On 22.02.17 15:11, Stavros 0 Sachtouris wrote:
>>>>>> Should I forward this to one of the lists as well?
>>>>> Yes, that probably would help getting more feedback on UI aspects.
>>>>>
>>>>> Best Regards
>>>>> Lukas
>>>>>
>>>>>
>>>>>
>>
>
> --
> Niels van Dijk Technical Product Manager Trust & Security
> Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
> SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
> www.surfnet.nlwww.openconext.org
>
Hi all,
I don't know if this is the right place to send this, but I will anyway.
I made some changes to the consent module. You can see the pull request
at github:
https://github.com/its-dirg/CMservice/pull/6
There are some screenshots as well.
Feedback is always appreciated.
