By: Pawel Pietrzynski named 21 Jun 2019 at 12:59 p.m. CDT

7 Responses
Pawel Pietrzynski gravatar
## Issue is relevant to 4.0 QA build and 3.1.6 I've been testing the QA build of 4.0 but the same issue exists in previous stable version. I understand the GUI is for a general passport provider, but SAML and OIDC (or other) are totally separate use cases, while synanymous in functionality work with totally different parameters, and so perhaps the GUI should be more customized towards each. ## Clarifying key/certificate the parameters Currently setting the parameters is confusing at best * IDP Signing Cert --- the "cert" attribute, although bothersome to serialize the certificate into a single string Probably the most clear, although the attribute should be named or referenced as "idpSignCert" or something similar * IDP Encryption Cert --- not supported, cannot encrypt SAML Request objects atm. * Passport SP Signing Cert --- "signingCert" attribute, name is confusing and specific to the IDP provider (should not be) * Passport SP Signing Key --- "privateCert" attribute, RSA PAM key string, name is confusing and specific to the IDP provider (should not be) * Passport SP Encryption Cert --- "decryptionCert" attribute, also "SP TLS cert" field for a file which is confusing because there is no TLS involved ... better than written in plaintext string too if put directly into an options attribute * Passport SP Encryption Key --- "decryptionPvk" attribute, also "SP TLS key" field which is confusing because there is no TLS involved ... better than written in plaintext string too if put directly into an options attribute map Instead of listing all the Passport SP data, perhaps building a passport SP profile(s) and referencing the sp name for each to be tied to that IDP provider ## Security of keys and signatures One of the two keys listed above for Passport SP Signing and Ecnryption are configurable in plaintext PAM format and any administrator can extract them, so both (privateCert as signing key) should be configurable the same way. Also the passport-sp cert/key files based on your documentation are for encryption while there are no signing cert/key pair directions Another choice that makes a lot of sense is to leverage a JKS keystore with aliases and there is a 'node-keytool' library that can help achieve that, which will help confidentiality on disk-level where security keys are not stored in plaintext. ## Importing of IDP metadata Ideally you should be able to pre-fill the IDP settings like entityId, callbackUrl, identifiers, certificate, logout, from a metadata file, which is how the integration data is exchanged normally instead of parsing through and configuring all the pieces manually.

By Jose Gonzalez staff 23 Jun 2019 at 7:26 a.m. CDT

Jose Gonzalez gravatar
Hi, We are discussing internally the points above. We'll get back to you.

By Pawel Pietrzynski named 26 Jun 2019 at 8:03 a.m. CDT

Pawel Pietrzynski gravatar
Just a note on the signing/encryption keys - they do not work as serialized one-line parameters, the only way I got them both to work is by editing saml.js and adding filesystem file read of the key file, which is a multi-line key. Additionally because they are not in a keystore but as ASCII files they are exposed to file system scraping and requiring encrypted backups, it'd be better if password protected keys were supported.

By Jose Gonzalez staff 29 Jun 2019 at 10:10 a.m. CDT

Jose Gonzalez gravatar
> they do not work as serialized one-line They do. This single line style has been in place for long and has never given trouble in QA stages, nor in production for our customers.

By Pawel Pietrzynski named 02 Jul 2019 at 11:22 a.m. CDT

Pawel Pietrzynski gravatar
Well, it did not work for me, took the same file, serialized it into one line and it would throw request signing error every time, spent hours debugging until I saw the passport documentation itself referring to "fs" library to read them which worked for me. I and I refer to signing and encryption keys, not certificates.

By Jose Gonzalez staff 05 Jul 2019 at 6:53 a.m. CDT

Jose Gonzalez gravatar
Hi, Sorry for the delay. So far we have the following comments, we haven't covered everything yet but we'd like to have some feedback on this before moving onto the other topics: > but SAML and OIDC (or other) are totally separate use cases They are all focused on inbound identity, that's why The GUI prefills the forms accordingly with the type of provider selected. All provider types are backed by passport-js strategies with no exception > the attribute should be named or referenced as "idpSignCert" or something similar I agree but we decided to use the names exactly as in the underlying strategy (passport-saml) [documentation](https://github.com/bergie/passport-saml/#config-parameter-details), thus the same applies for `privateCert`, and so. Otherwise this will add more confusion. In theory, admins should visit such page and provide params as needed. We are not contributors or owners of that repository. We can suggest but it is not very likely they switch the naming due to the their existing user base > IDP Encryption Cert & Passport SP Signing Cert Can you point which params are these (ie where in the UI you were trying to set it) ? or you meant this is something desirable but unsupported > Passport SP Signing Key --- "privateCert" Yes, it's not IDP-specific. Actually `privateCert` = "SP TLS cert" which is in the global passport configuration page. We need to clarify this in our docs, so admins don't provide `privateCert`. Do you have a suggestion for a good name for this one? > Passport SP Encryption Key --- "decryptionPvk" Likewise, `decryptionPvk` = spTLSKey. Let us know your name suggestion

By Pawel Pietrzynski named 09 Jul 2019 at 8:49 a.m. CDT

Pawel Pietrzynski gravatar
> I agree but we decided to use the names exactly as in the underlying strategy (passport-saml) documentation, thus the same applies for privateCert For all confusing provider parameters/names in that case I would suggest pre-fill the description/instruction in the property value field with 10 words or less, such as "Paste PEM format signing SP certificate here, see documentation for details" That would go for the "cert" parameter of the provider configuration for example. For all configurations that apply to Passport SAML SP strategy globally, I would put them in the genral config. Currently only one certificate/key pair is generated, I would generate two where one for signing and one for encryption. > IDP Encryption Cert They are not supported by passport in the current release. Each direction in SAML can Sign and/or encrypt a message. Generally it's rare to encrypt SAML Requests, but sometimes it is required and current passport strategy does not support it. An example use case is encrypting NameID in SAML Logout Request. > Passport SP Signing Key --- "privateCert", actually privateCert = "SP TLS cert" That's not accurate, privateCert is a key in fact (see mapping in original description). The `SP TLS cert` refers to `decryptionCert` instead having looked into the code. There is no TLS component in SAML, even though TLS is used in transfer it's part of network socket configuration. For the naming based on other products here are some simple names I believe would work - `signingCert` = `SP Signature Verification Certificate` - `privateCert` = `SP Signing Private Key` - `decryptionCert` = `SP Encryption Certificate` - `decryptionPvk = spTLSKey` = `SP Decryption Private Key` Hope that helps

By Jose Gonzalez staff 20 Jul 2019 at 7:57 a.m. CDT

Jose Gonzalez gravatar
Hi, > The SP TLS cert refers to decryptionCert you are right. So far we have created the following issues for enhancement: https://github.com/GluuFederation/docs-ce-prod/issues/201 https://github.com/GluuFederation/oxTrust/issues/1734 https://github.com/GluuFederation/gluu-passport/issues/69