Re: [pve-devel] RE : RE : [PATCH] [PATCH pve-access-control] SSO feature:login with SAMLv2

Re: [pve-devel] RE : RE : [PATCH] [PATCH pve-access-control] SSO feature:login with SAMLv2

[Dietmar Maurer]

> On 06/02/2021 12:16 PM wb <webmaster@jbsky.fr> wrote:
> 
> 
> > I also wonder why SAML? Would it be an option to use OpenId connect instead?
> As I was able to use SAML, I know the functional part and therefore, if I used SAML, it is only by ease.
> 
> Switch to OpenID, why not. The time I set up a functional POC.
> 
> On the other hand, I would like to know your constraints.

Sorry, what do you want to know exactly?

> Do you still want to use Rust? 

Yes. But I am still searching for usable crates:

openidconnect: https://github.com/ramosbugs/openidconnect-rs

Seems promising, but I have not done any testing so far...

> If yes, I am curious to know how to bind perl to Rust? Do you have an example?

https://git.proxmox.com/?p=perlmod.git;a=summary

Hope the inline docs and examples are good enough to start...

> I noticed from our exchange :
> During an API call, if the user is not authenticated, do not pass in private and privileged the writing on /tmp/.

yes, unprivileged users should not be able to write anything.

Re: [pve-devel] [PATCH] [PATCH pve-access-control] SSO feature:login with SAMLv2

[Victor Hooi]

Hi,

I'm super excited to see this SSO support come to Proxmox. This is really
awesome stuff!

One question - I wonder if it would be possible to use Google
Workspace/Google Auth as the SAMLv2 IDP?

I'm definitely not an auth expert, but from casual reading, I think it
might be possible via setting up a custom SAML application, per this guide:

https://support.google.com/a/answer/6087519

What do you think?

I went into one of my Google Workspace domains, and tried adding a new
custom SAML app. It then gives you a confirmation page, where you can
download an IdP metadata file (.xml) - excerpted below:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="https://accounts.google.com/o/saml2?idpid=C02hq58w2" validUntil=
"2026-01-18T05:49:17.000Z">
<md:IDPSSODescriptor WantAuthnRequestsSigned="false"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
MIIDdDCCAlygAwIBAgIGAXcZMLKUMA0GCSqGSIb3DQEBCwUAMHsxFDASBgNVBAoTC0dvb2dsZSBJ
bmMuMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MQ8wDQYDVQQDEwZHb29nbGUxGDAWBgNVBAsTD0dv
b2dsZSBGb3IgV29yazELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWEwHhcNMjEwMTE5
MDU0OTE3WhcNMjYwMTE4MDU0OTE3WjB7MRQwEgYDVQQKEwtHb29nbGUgSW5jLjEWMBQGA1UEBxMN
TW91bnRhaW4gVmlldzEPMA0GA1UEAxMGR29vZ2xlMRgwFgYDVQQLEw9Hb29nbGUgRm9yIFdvcmsx
CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAqXFeh4hdnVNM0NbmrU7DhyZr5fb9l/2s2kohFJgfT2b6nI+3uqLf6eKoQSMfO9Fc
WZaWVIXDD9bFncaGMxeqcNjcSo5TS4jc3x3k5es0Phjf/nJZxCLXWsFFpvLY5LT37aX88sJoAYc6
vPZCOo7t+DO/c/H2Kmx26selDVKHMhQWP3k2UJiPAIF4xT3hglkSgiCkvZBjDNqfTVAkuwt1hNIy
DH7vqriwn+XHgA/kwlTb78IxU55hVC31V6LlnqPGoilsze4ueGFw3MF00RMSZd+sQpXZQ6751OVH
hazyHXS0Rscd4/GTfkKXEHh3/uJlTxlzIkq+76E4m0J6X1U1yQIDAQABMA0GCSqGSIb3DQEBCwUA
A4IBAQAkp4W796dK5r7cYan0MeEYaa9qEquxleiviB4J9s5iM45WUChJNF7pYaML+gdWfLasYb9B
mJqnG1ZsuH7DsDyr2hkVgGZPav23ZX9S4jAW5w+OsMmVm92MOsNocl4P9uM86WcMJy7eiGe2KIre
cSxVfIAsO0hGM7ZZHkH+knjYc6Sq5BnHVtxSGX4a6OlxI56XBpAA22H3egBNGknrglmrVUD2VOCT
z9ePxsPnW+CCzD4gPJJHBdliB2GhN/gYUKwyvXesvd8/TlsntzEpdBctnc83rnfCUF6Rx67Kn54c
FCaLUeQtqtUjHUK5eRCFU9XNc74oR8AvCHqB9owP3Zvs</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</
md:NameIDFormat>
<md:SingleSignOnService Binding=
"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="
https://accounts.google.com/o/saml2/idp?idpid=C02hq58w2"/>
<md:SingleSignOnService Binding=
"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="
https://accounts.google.com/o/saml2/idp?idpid=C02hq58w2"/>
</md:IDPSSODescriptor>
</md:EntityDescriptor>

SSO URL - https://accounts.google.com/o/saml2/idp?idpid=C02hq58w2
Entity ID - https://accounts.google.com/o/saml2?idpid=C02hq58w2
Certificate - <ETC>

What do you think - would this work with your integration?

I'm willing to set up a Google Workspace domain for testing, and grant
access to anybody for testing?

Thanks,
Victor

On Wed, Jun 2, 2021 at 8:48 PM Dietmar Maurer <dietmar@proxmox.com> wrote:

>
> > On 06/02/2021 12:16 PM wb <webmaster@jbsky.fr> wrote:
> >
> >
> > > I also wonder why SAML? Would it be an option to use OpenId connect
> instead?
> > As I was able to use SAML, I know the functional part and therefore, if
> I used SAML, it is only by ease.
> >
> > Switch to OpenID, why not. The time I set up a functional POC.
> >
> > On the other hand, I would like to know your constraints.
>
> Sorry, what do you want to know exactly?
>
> > Do you still want to use Rust?
>
> Yes. But I am still searching for usable crates:
>
> openidconnect: https://github.com/ramosbugs/openidconnect-rs
>
> Seems promising, but I have not done any testing so far...
>
> > If yes, I am curious to know how to bind perl to Rust? Do you have an
> example?
>
> https://git.proxmox.com/?p=perlmod.git;a=summary
>
> Hope the inline docs and examples are good enough to start...
>
> > I noticed from our exchange :
> > During an API call, if the user is not authenticated, do not pass in
> private and privileged the writing on /tmp/.
>
> yes, unprivileged users should not be able to write anything.
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>

Re: [pve-devel] RE : [PATCH] [PATCH pve-access-control] SSO feature:login with SAMLv2

[Dietmar Maurer]

> > I wonder why you want to store temporary data in /etc/pve/tmp/saml. Wouldn't it we good enough
> > to store that on the local file system?
> On the one hand, I enjoyed reusing your work.
> On the other hand, I think it is more secure to put this kind of data in /etc/pve/tmp/saml than in /tmp/saml/

No, I consider this less secure. Especially if the write is triggered by unauthenticated request...

> Then, yes, it is possible to store it on /tmp/saml for example, it is variable data. Nothing is fixed, you are free to do what you want.
> 
> > Unfortunately, your code depends on code not packaged for Debian. Any idea
> > how to replace that (cpanm Net::SAML2)?
> 
> Since I'm not a perl specialist, I took what seemed to me the most standard in this language. Have you considered cloning this repos available on GitHub(https://github.com/perl-net-saml2/perl-Net-SAML2)?

This module has way to much dependencies (Moose). I do not want to use that.

> > Or better, is there a 'rust' implementaion for SAML2? If so, we could make perl bindings
> > for that and reuse the code with Proxmox Backup Server.
> 
> Do you have a specific project or library in mind?
> 
> Unfortunately, I don't have any knowledge about rust and I'll have a hard time accompanying you on this topic. However, it seems that there are projects on github in opensource, for example https://github.com/njaremko/samael.

All those SAML libs are basically unmaintained, without any large user base.

> I'll tell you again,nothing is fixed, you are free to do what you want.

I also wonder why SAML? Would it be an option to use OpenId connect instead?

[pve-devel] RE : RE : [PATCH] [PATCH pve-access-control] SSO feature:login with SAMLv2

[wb]

> I also wonder why SAML? Would it be an option to use OpenId connect instead?
As I was able to use SAML, I know the functional part and therefore, if I used SAML, it is only by ease.

Switch to OpenID, why not. The time I set up a functional POC. 

On the other hand, I would like to know your constraints.

Do you still want to use Rust? If yes, I am curious to know how to bind perl to Rust? Do you have an example?
I noticed from our exchange :
During an API call, if the user is not authenticated, do not pass in private and privileged the writing on /tmp/.

Waiting for your feedback,

Sincerely,

Julien Blais


De : Dietmar Maurer
Envoyé le :mercredi 2 juin 2021 11:00
À : wb; Proxmox VE development discussion
Objet :Re: RE : [pve-devel] [PATCH] [PATCH pve-access-control] SSO feature:login with SAMLv2

> > I wonder why you want to store temporary data in /etc/pve/tmp/saml. Wouldn't it we good enough
> > to store that on the local file system?
> On the one hand, I enjoyed reusing your work.
> On the other hand, I think it is more secure to put this kind of data in /etc/pve/tmp/saml than in /tmp/saml/

No, I consider this less secure. Especially if the write is triggered by unauthenticated request...

> Then, yes, it is possible to store it on /tmp/saml for example, it is variable data. Nothing is fixed, you are free to do what you want.
> 
> > Unfortunately, your code depends on code not packaged for Debian. Any idea
> > how to replace that (cpanm Net::SAML2)?
> 
> Since I'm not a perl specialist, I took what seemed to me the most standard in this language. Have you considered cloning this repos available on GitHub(https://github.com/perl-net-saml2/perl-Net-SAML2)?

This module has way to much dependencies (Moose). I do not want to use that.

> > Or better, is there a 'rust' implementaion for SAML2? If so, we could make perl bindings
> > for that and reuse the code with Proxmox Backup Server.
> 
> Do you have a specific project or library in mind?
> 
> Unfortunately, I don't have any knowledge about rust and I'll have a hard time accompanying you on this topic. However, it seems that there are projects on github in opensource, for example https://github.com/njaremko/samael.

All those SAML libs are basically unmaintained, without any large user base.

> I'll tell you again,nothing is fixed, you are free to do what you want.

I also wonder why SAML? Would it be an option to use OpenId connect instead?