You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment the following (here relevant) SAML related fields are defined:
# Saml settings # [...] saml_metadata_idp:
type: text restriction_mode: A saml_metadata_sp:
type: text restriction_mode: A saml_private_key:
type: text restriction_mode: A
As far as I know these are set with a simple organization.update action issued by the client.
This is very error prone and should instead be mostly automated.
It requires the end user to manually generate and input a keypair and metadata for SP (OpenSlides), see OpenSlides/openslides-client#2944.
I think the backend should just provide an action to automatically generate the needed information, like organization.generate_saml_metadata.
This should then generate a x509 key pair and use it's public key and other relevant information from the database (such as URL) to construct saml_metadata_sp.
The organization.update action should then forbid changing saml_metadata_sp and saml_private_key manually.
For implementing this the backend probably should utilize the python3-saml module for which inspiration may be found at https://github.com/OpenSlides/OpenSlides/tree/stable/3.4.x/server/openslides/saml
However OpenSlides 3 did not generate the keypair within the code so this has to be researched.
I am pretty confident though, a good stable library for this exists.
The generated key pair should be equivalent to the output of
Also IdP's usually provide their metadata xml via an http route. So I think it would also be more user-friendly and intuitive to change the saml_metadata_idp to saml_metadata_idp_url, although this is not as important and may also be debatable.
This of course would also implicate that the URL must be queried at some point and I am not sure if the backend should be the one doing that. So maybe - if at all - this should be in the client which would then keep sending the xml to the backend.
The text was updated successfully, but these errors were encountered:
Another thing I forgot to mention.
Currently only the superadmin has the permission to change SAML related fields.
This should also be changed such that an organization admin can configure SAML on his own.
Since this issue is a year old and a lot has happend in the SAML field since then, I'd guess it may possibly be a bit out-of-date by now.
@rrenkert@peb-adr How does this issue relate to the current SAML development? Could you arrange to have it updated with current specs if it is outdated?
At the moment the following (here relevant) SAML related fields are defined:
As far as I know these are set with a simple
organization.update
action issued by the client.This is very error prone and should instead be mostly automated.
It requires the end user to manually generate and input a keypair and metadata for SP (OpenSlides), see OpenSlides/openslides-client#2944.
I think the backend should just provide an action to automatically generate the needed information, like
organization.generate_saml_metadata
.This should then generate a x509 key pair and use it's public key and other relevant information from the database (such as URL) to construct
saml_metadata_sp
.The
organization.update
action should then forbid changingsaml_metadata_sp
andsaml_private_key
manually.For implementing this the backend probably should utilize the
python3-saml
module for which inspiration may be found at https://github.com/OpenSlides/OpenSlides/tree/stable/3.4.x/server/openslides/samlHowever OpenSlides 3 did not generate the keypair within the code so this has to be researched.
I am pretty confident though, a good stable library for this exists.
The generated key pair should be equivalent to the output of
Also IdP's usually provide their metadata xml via an http route. So I think it would also be more user-friendly and intuitive to change the
saml_metadata_idp
tosaml_metadata_idp_url
, although this is not as important and may also be debatable.This of course would also implicate that the URL must be queried at some point and I am not sure if the backend should be the one doing that. So maybe - if at all - this should be in the client which would then keep sending the xml to the backend.
The text was updated successfully, but these errors were encountered: