Merge pull request #297743 from PhilKang0704/broken-link-fix-jegeib

Broken links fixing - jegeib

Author: JamesJBarnett

articles/security/develop/threat-modeling-tool-authentication.md

@@ -224,7 +224,7 @@ ms.custom: devx-track-csharp
 | **SDL Phase**               | Build |
 | **Applicable Technologies** | Generic |
 | **Attributes**              | N/A  |
-| **References**              | [IdentityServer3 - The Big Picture](https://identityserver.github.io/Documentation/docsv2/overview/bigPicture.html) |
+| **References**              | N/A |
 | **Steps** | <p>Below are the typical interactions supported by Identity Server:</p><ul><li>Browsers communicate with web applications</li><li>Web applications communicate with web APIs (sometimes on their own, sometimes on behalf of a user)</li><li>Browser-based applications communicate with web APIs</li><li>Native applications communicate with web APIs</li><li>Server-based applications communicate with web APIs</li><li>Web APIs communicate with web APIs (sometimes on their own, sometimes on behalf of a user)</li></ul>|
 
 ## <a id="override-token"></a>Override the default Identity Server token cache with a scalable alternative
@@ -235,7 +235,7 @@ ms.custom: devx-track-csharp
 | **SDL Phase**               | Deployment |
 | **Applicable Technologies** | Generic |
 | **Attributes**              | N/A  |
-| **References**              | [Identity Server Deployment - Caching](https://identityserver.github.io/Documentation/docsv2/advanced/deployment.html) |
+| **References**              | N/A |
 | **Steps** | <p>IdentityServer has a simple built-in in-memory cache. While this is good for small scale native apps, it does not scale for mid tier and backend applications for the following reasons:</p><ul><li>These applications are accessed by many users at once. Saving all access tokens in the same store creates isolation issues and presents challenges when operating at scale: many users, each with as many tokens as the resources the app accesses on their behalf, can mean huge numbers and very expensive lookup operations</li><li>These applications are typically deployed on distributed topologies, where multiple nodes must have access to the same cache</li><li>Cached tokens must survive process recycles and deactivations</li><li>For all the above reasons, while implementing web apps, it is recommended to override the default Identity Server's token cache with a scalable alternative such as Azure Cache for Redis</li></ul>|
 
 ## <a id="binaries-signed"></a>Ensure that deployed application's binaries are digitally signed

articles/security/develop/threat-modeling-tool-communication-security.md

@@ -71,7 +71,7 @@ ms.custom: devx-track-csharp
 | **SDL Phase**               | Deployment |  
 | **Applicable Technologies** | Generic |
 | **Attributes**              | N/A  |
-| **References**              | [IdentityServer3 - Keys, Signatures and Cryptography](https://identityserver.github.io/Documentation/docsv2/configuration/crypto.html), [IdentityServer3 - Deployment](https://identityserver.github.io/Documentation/docsv2/advanced/deployment.html) |
+| **References**              | N/A |
 | **Steps** | By default, IdentityServer requires all incoming connections to come over HTTPS. It is absolutely mandatory that communication with IdentityServer is done over secured transports only. There are certain deployment scenarios like TLS offloading where this requirement can be relaxed. See the Identity Server deployment page in the references for more information. |
 
 ## <a id="x509-ssltls"></a>Verify X.509 certificates used to authenticate SSL, TLS, and DTLS connections

articles/security/develop/threat-modeling-tool-cryptography.md

@@ -218,7 +218,7 @@ As can be seen, the device primary key is not present in the code. Instead, it i
 | **SDL Phase**               | Deployment |  
 | **Applicable Technologies** | Generic |
 | **Attributes**              | N/A  |
-| **References**              | [Identity Server - Keys, Signatures and Cryptography](https://identityserver.github.io/Documentation/docsv2/configuration/crypto.html) |
+| **References**              | N/A |
 | **Steps** | Ensure that signing keys are rolled over when using Identity Server. The link in the references section explains how this should be planned without causing outages to applications relying on Identity Server. |
 
 ## <a id="client-server"></a>Ensure that cryptographically strong client ID, client secret are used in Identity Server

articles/security/develop/threat-modeling-tool-session-management.md

@@ -123,7 +123,7 @@ services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationSch
 | **SDL Phase**               | Build |  
 | **Applicable Technologies** | Generic |
 | **Attributes**              | N/A  |
-| **References**              | [IdentityServer3-Federated sign out](https://identityserver.github.io/Documentation/docsv2/advanced/federated-signout.html) |
+| **References**              | N/A |
 | **Steps** | IdentityServer supports the ability to federate with external identity providers. When a user signs out of an upstream identity provider, depending upon the protocol used, it might be possible to receive a notification when the user signs out. It allows IdentityServer to notify its clients so they can also sign the user out. Check the documentation in the references section for the implementation details.|
 
 ## <a id="https-secure-cookies"></a>Applications available over HTTPS must use secure cookies