Certificates and Tokens
- Jana Volencová (Deactivated)
- Christian Tratz
Certificates are used to establish „trust“ between two parties. Certificates always consist of a public part and a private one. Usually the certificate issuer keeps the private portion secret and publishes in some form the public part.
Certificates always have a lifetime (also called expiry date). Sometimes it is long (multiple years) but the trend is to have shorter expiry (months). Only the owner of the private part can renew a certificate. Hence it is this parties‘ responsibility to renew a certificate
We have use cases where Pricefx owns the private part (e.g. SSL certificates for web services we expose) as well as where we only use/import a public part from someone else (e.g. SAML SSO).
Type of Certificate | Area | Purpose | Owner / Process | Resources |
|---|---|---|---|---|
TLS/SSL certificates (Pricefx exposes a web service or page) | Access to Pricefx operated web services. Anything under the domains https://<somename>.pricefx.com and https://<somename>.pricefx.eu. | To secure the communication connection (data-in-transit encryption). These certificates are all signed and trusted by a commonly acknowledged Certificate Authority (CA) which are commonly trusted by all major browsers. I.e. even after a certificate changes, any client should trust the new certificate by a shared CA trust. Mileage varies for other clients (in particular in integration space). Please be aware that – following general industry and browser standards and recommendations – we aim for shorter certificate lifetimes (a few months). So expect regular certificate rollovers. Please also note that we follow standard common security practices around the support and – more importantly – the de-support of old and outdated security/encryption properties such as ciphers and encryption protocols. Most notably, we only support TLS 1.2 or newer and only cipher suites that are considered “strong”. Very old and outdated clients may not support these. | These certificates are maintained by Pricefx. | https://api.pricefx.com/rest-api/authentication/ https://pricefx.atlassian.net/wiki/spaces/KB/pages/3664347149 https://pricefx.atlassian.net/wiki/spaces/KB/pages/3673391182 |
TLS/SSL certificates (Pricefx as client) | Access to outside web services (customer or public). | To secure the communication connection. Just like above, but reverse. Pricefx (should) trust all commonly used CA signed certificates. However, if e.g. the customer uses self-signed certificates, they (their public part) need to be imported client-side to be trusted. | The owner of the certificate needs to renew and distribute the updated public parts before the expiry date. |
|
Single sign-on (SAML Certificate) | User login to Pricefx applications | Enables single sign-on to Pricefx applications. Certificates are used to verify the SAML signature and ensure that the login grant comes from a trusted source (the Identity Provider). For this purpose Pricefx needs to know the public certificate part from the Identity Provider to validate the signature. Most common identity providers roll over (renew) these certificates on a regular basis. | Customer IT department issues this certificate and distributes it manually to Pricefx for installation or publishes it in the federationmetadata.xml manifest (which needs to be set as trust anchor in Pricefx). | https://pricefx.atlassian.net/wiki/spaces/UNITY/pages/4611573082 |
Found an issue in documentation? Write to us.