Home How it works, BrieflyBest PracticesAPI Dependencies (Getting Ready)API Preparations (Setup)API Operating ModeHTTPS Based Certificate DetectionHTTP Certificate IdentificationRedirect IntentsLegacy Certificate Detection RequestGuided RegistrationAPI MethodsValidating A CertificateSimple ResponsesAccount BindingPlacing an off-site secretAdding Tokens Of TrustDisconnecting AccountsReporting an IntrusionsConflict ResolutionActivity DiagramReturn CodesTrust NormalizationTrust Anchors |
Best PracticesThis is a brief check-list of practices that are meant to make the best of your identity service. We're going to updated it with common problems and solutions, so if you have a questions you cannot find the answer to, please feel free to send it to us. Updating CertificatesYour API certificate has an expiration date, which is usually one year from the moment of issuing. You will receive a notification prior to this event, but it is your duty to renew the certificate and update it on your server. Please make sure you keep up to date information in your profile so that our notifications reach you. If your API certificate expires the SSL system will not accept it your service will not be able to connect to the identity API interface, which can result in business disruptions. However, you do not need to wait until your certificate expires. These are not Server SSL certificates and you will not be charged for renewing a them even if you are running a business environment. As a best practice, for safety, you should renew your API certificates when they reach two thirds of their life. This is also a good security measurement. Reverse - ProxiesThere are two ways reverse proxies can be used in conjunction with Identity plus: pass through mode, and SSL In case you are using a reverse proxy for your server, the recommended way is HTTPS Pass-Through mode, or TCP relaying because the server can only detect the client certificate if the server itself is running over HTTPS. If HTTPS is off-loaded on the reverse proxy, your application is in fact running on HTTP and you lose access to client certificates. That said, reverse proxies can forward the / some client certificate details, like CNAME to the downstream server in http headers. CNAME is all that is needed to verify the client certificate against the identity API, therefore this is a valid way of doing it, however, this does require extra implementation and there is one important note:
Implementation Check-List
For SSL Enabled Server
Important
|