Document ServiceControl / ServicePulse support for authentication and SSL/TLS#7947
Document ServiceControl / ServicePulse support for authentication and SSL/TLS#7947jasontaylordev merged 27 commits intomasterfrom
Conversation
jasontaylordev
requested review from
warwickschroeder
and removed request for
warwickschroeder
jasontaylordev
force-pushed
the
genxp-3600-add-authentication
branch
from
ee39943 to
576ea1b
Compare
…steps and configuration examples
jasontaylordev
force-pushed
the
genxp-3600-add-authentication
branch
from
175b8ea to
604ff09
Compare
- Renamed "HTTPS" to "TLS" in menu.yaml and added "CORS" section. - Enhanced configuration documentation for HTTP to HTTPS redirection in audit and monitoring instances. - Added new settings for HTTPS port in ServiceControl configuration. - Introduced CORS configuration documentation for ServiceControl instances. - Updated authentication documentation to clarify the use of Microsoft Entra ID and other OIDC providers. - Added TLS configuration documentation detailing direct HTTPS and reverse proxy setups. - Improved overall security overview and deployment scenarios in the ServiceControl documentation.
|
I noticed we refer to Kestrel, I understand a dotnet dev probably knows what that is, but i am wondering if a ops person that is installing and configuring SC and SP would know what that means? |
|
This page has not been updated at all, I was expecting to see some changes there |
servicecontrol/security/configuration/tls-troubleshooting.include.md
Outdated
Show resolved
Hide resolved
| - servicecontrol/security/hosting-guide | ||
| --- | ||
|
|
||
| Cross-Origin Resource Sharing (CORS) controls which web applications can make requests to ServiceControl. This is important when ServicePulse is hosted on a different domain than ServiceControl. |
There was a problem hiding this comment.
isn't it also important if ServicePulse is hosted on the same domain but a different port? Essentially it's required unless SP is hosted out of SC, which hasn't been released yet
There was a problem hiding this comment.
The port does matter, so we should probably add this. Its also worth noting that by default, CORS allows all origins. So if the customer doesn't change this, the request from the same host but different port will succeed.
|
|
||
| **Symptom**: ServicePulse displays connection errors or fails to load data, and browser developer tools show CORS errors like "Access-Control-Allow-Origin" or "blocked by CORS policy". | ||
|
|
||
| **Cause**: The ServicePulse origin is not in the allowed origins list, or the origin URL doesn't match exactly (including protocol and port). |
There was a problem hiding this comment.
there is no reference made to port anywhere above
There was a problem hiding this comment.
We should add info about the port and protocol where you flagged this higher up in the doc
|
|
||
| _Added in version 6.11.0_ | ||
|
|
||
| Trusts forwarded headers from any source. Set to `false` when using `KnownProxies` or `KnownNetworks`. |
There was a problem hiding this comment.
Set to
falsewhen usingKnownProxiesorKnownNetworks.
this is ambiguous in its meaning. Should it be:
- Set this to
falsewhen usingKnownProxiesorKnownNetworks; or - This is set to
falsewhen usingKnownProxiesorKnownNetworks?
the warning below suggests the former
There was a problem hiding this comment.
So the warning is just making it clear that its recommended that this setting should be set to false, however which way that is done. But the user can either set it explicitly, or if the users sets KnownProxies or KnownNetworks, then this setting is automatically set to false. So it should be latter.
* spelling and grammar review of #7947
5 participants
Add security documentation for the following PRs: