###### tags: `程式語言`

# Keycloak筆記
Ref：[Keycloak快速上手指南](https://iter01.com/509140.html)

> Keycloak提供了單點登入（SSO）功能，支援OpenID Connect、OAuth 2.0、SAML 2.0標準協議，擁有簡單易用的管理控制檯，並提供對LDAP、Active Directory以及Github、Google等社交賬號登入的支援，做到了非常簡單的開箱即用。

**一句話解釋SSO：
透過單一的登入窗口，進行單一的身分驗證，就可以讓許多的服務共同來使用這個驗證結果**

4個最常用的核心概念：

Users：使用者，使用並需要登入系統的物件。

Roles：角色，用來對使用者的許可權進行管理。

Clients：客戶端，需要接入Keycloak並被Keycloak保護的應用和服務。

Realms：領域，領域管理著一批使用者、證照、角色、組等。
一個使用者只能屬於並且能登陸到一個域，域之間是互相獨立隔離的，一個域只能管理它下面所屬的使用者。

[>>可以參考此圖<<](https://i.iter01.com/images/1f0454b9ce821e420363a3d6931ed11ef011ebbeb9a4bac045dde14548098cf7.png)

# ADFS
Ref：[運用 ADFS 作為 GCP 外部身分認證](https://blog.cloud-ace.tw/identity-security/ad-adfs-cloudidentity/)

* AD
可以把 AD 視為一個內部的帳戶資料庫。而這麼一個建置完整的帳戶系統，如果只能在內部使用那就太可惜了。於是乎，微軟便推出了 ADFS 服務，透過 ADFS 的 Single Sign On （SSO）機制，我們就能讓外部機構或是軟體服務以既有的 AD 帳戶作為驗證。

* SSO (using SAML? 還是keycolak? >>答案是keycloak支援SAML)
Ref：[SAML簡介](https://www.oracle.com/tw/security/cloud-security/what-is-saml/)
透過單一的登入窗口，進行單一的身分驗證，就可以讓許多的服務共同來使用這個驗證結果，這就是SSO扮演的角色。

每當我們登入帳戶成功，我們便會獲得一個 SSO Token，我們可以透過傳遞這個 Token 來讓不同的服務能獲取用戶資訊並判斷其權限，從而能靠一次的帳戶登入來在不同服務間通行無阻。所以透過 ADFS 的 SSO 機制，我們就能把 AD 中的用戶資訊在驗證後打包出來給其他服務使用。
[>>可以參考此圖<<](https://storage.googleapis.com/cloudace-tw-blog/1/2021/09/AD-blog-images-21-2.png)

* ADFS服務組成
簡單來說，ADFS 的服務可以拆分成存放用戶資料的 AD 服務、依照 Request 讀取 AD 資料並封裝 Token 的 Federation 服務、為了保護 AD 資料而增加的中間層 Federation Server Proxy 服務、作為窗口接收 Request 並管理認證 Token 的網站伺服器。透過這些服務即可以讓用戶從外部網站進行第三方的認證程序：

   ADFS web 伺服器：用來管理回傳給外部認證用的 Token 與 cookie。
    
   Federation 伺服器代理服務：接收外部 Request 並傳送給 Federation 服務。
    
   ederation 服務：處理外部 Request 並處理、回傳包含用戶資訊的 Token。
    
   Active Directory 服務：用來存放用戶資料並被 ADFS 所使用。

* ADFS流程
當我們今天希望使用某個服務的時候，我們會對服務的供應商（Service Provider, SP）發出一個進入的請求，而今天這個 SP 使用了 ADFS 作為 SSO 認證的工具，所以他會來看看我們有沒有這個從 ADFS 獲取的 Token。而因為是第一次登入，我們手上並沒有這個 Token，於是乎 SP 便把我們的請求轉給了 ADFS 。

ADFS 會要求我們輸入帳號與密碼來 ㄒ 驗證是否具有資料的存取權，如果有的話，ADFS 會基於預先設定好的宣言規則（Claim rule）從 AD 獲取對應的用戶資料來轉換給到 SP，並加密成 Token 來發行（Issue）給我們，我們就可以把這個 Token 給到 SP，進而獲取進入的許可。以上就是一個完整的 ADFS 外部認證流程。
[>>可以參考此圖<<](https://storage.googleapis.com/cloudace-tw-blog/1/2021/09/AD-blog-images-22.png)

# OAuth2
Ref：
[[筆記] 認識 OAuth 2.0：一次了解各角色、各類型流程的差異](https://medium.com/%E9%BA%A5%E5%85%8B%E7%9A%84%E5%8D%8A%E8%B7%AF%E5%87%BA%E5%AE%B6%E7%AD%86%E8%A8%98/%E7%AD%86%E8%A8%98-%E8%AA%8D%E8%AD%98-oauth-2-0-%E4%B8%80%E6%AC%A1%E4%BA%86%E8%A7%A3%E5%90%84%E8%A7%92%E8%89%B2-%E5%90%84%E9%A1%9E%E5%9E%8B%E6%B5%81%E7%A8%8B%E7%9A%84%E5%B7%AE%E7%95%B0-c42da83a6015)
[OAuth的知識觀念介紹](https://medium.com/skyler-record/oauth%E4%BB%8B%E7%B4%B9-1bdb1e579e64)

**OAuth 基本流程**

 +--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

**Refresh Token 流程**

 +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

A. Client透過 Authorization Grant向 Authorizatino Server來申請 Access Token。
B. Authorization Server驗證Authorization Grant。如果都合法就核發Access Token。
C. Client 透過取得的Access Token向Resource Server發出Protected Resources的請求。
D. Resource Server驗證Access Token，如果合法就處理該請求。
E. 步驟(C)和(D)一直重覆，直到 Access Token 過期。如果 Client 自己知道 Access Token 過期，就跳到(G)。否則就發送另一個Protected Request的請求。
F. 因為Access Token不合法，所以Resource Server回傳 Token 不合法的錯誤。
G. Client 透過Refresh Token向Authorization Server請求新的Access Token。
H. Authorization Server驗證 Refresh Token，如果合法就核發新的Access Toke （也可以同時核發新的 Refresh Token）。
> OAuth2是一種授權機制

今天你使用Google帳號去登入Medium，此時有幾個角色：

1. Resouce Owner (你)
2. Client (Medium)
3. Authorization Server (Google)
4. Resource Server (Google的server)

# Web Server -- Nginx
Ref：[[Day 07] Web Server & Nginx — (1)](https://ithelp.ithome.com.tw/articles/10240487)
用途：反向代理、Http Cache、負載平衡。

正向代理與反向代理
講解這兩個概念之前，我們得先在心中描繪出一個圖：
> 一個 Client ，一個 Server，中間夾著一個 proxy。

**正向代理：**

生活舉例：
老爸(client)因為之前欠銀行錢沒有還，所以沒辦法再跟銀行(server)貸款，但是急需用錢呀，
於是跟我老姐(proxy)借了身份來貸款，因此銀行只知道它把錢借給了信用紀錄良好的我老姐，
而不知道拿到錢的事實上是之前沒還錢的老爸 QQ

技術術語：
Client 端發送一個 request 先連到proxy server，proxy server 幫我轉發到我想要連到的網站，這時那個網站收到的request，他只知道請求過來的身分是 proxy server，而不知道真實的 client 的身分。

**反向代理：**

既然是反向那概念就是正向代理的相反了。

生活舉例：
Dcard 的網站或 App 每天都會有使用者回報服務的異常與問題，而使用者只知道他跟 Dcard 內部反映問題了，卻不知道是 Dcard 的哪位員工看到了他的回應並去做處理，而使用者實際上也不在乎是誰看到他的訊息的，只要問題有順利解決就好。

技術術語：
Client 端發送一個 request 到我想要連的網站，這個網站背後可能就會有好幾台的 Server 來為我們服務（ex: 負載平衡），為了應付高流量的狀況，會將請求分配到不同的 Server，而 Client 根本不會知道具體到底是哪一台 Server，而 Client 也不需要知道，Client 只需要知道反向代理 Server是誰就好。

一句話總結兩種 Proxy：

> 正向代理隐藏真實 Client，反向代理隱藏真實 Server

# Application Server -- JBoss
//TODO

# Web Socket
建立WebSocket連線的過程：

Client送出Request，Request Header裡面會有handshake需要的資訊。
如果資訊驗證有問題，Server就會中斷連線。
Server收到Request後，會送出一個Response Header，讓Client根據裡面的資訊做驗證。
Client驗證OK，之後就繼續連線，Client可以透過這個連線送資料給Server，
Server也可以透過這個 連線送資料給Client，任何一方都可以透過這個連線送資料。
Client驗證有錯，就中斷連線。
所以，連線這個動作必須要Client發起，但是之後的資訊傳輸，就沒有限制。

---

* VM vs. Container(OCP) ，兩種做法目標：將一個應用程式所需的執行環境打包起來，建立一個獨立環境，方便在不同的硬體中移動。
* CICD目的&流程：CI是自動且統一地Build程式，CD是將程式佈到機器上。因此流程會是
OCP > Jenkins(CI) > OCP(CD)