SOA的安全議題
如同一般系統，SOA也有中央控制權限，除了使用者權限之外，還包含整個服務提供過程中的訊息安全，其複雜度遠較一般單一系統複雜許多，需要特別闢一個段落來說明，分開討論如下，
1. 使用者權限
一般系統都會有自己的中央權限來進行單一系統，SOA也不例外，但SOA是統整各服務協同運作之用，它必須有一致的權限控制能力，同時又需要相容於其他系統，特別是已存在系統(Legacy System)，將大幅的提高設計上的難度，涉及到的工作如下。
(1) 使用者資料整合
首先，就是使用者資料的整合，如果使用者資料無法整合，將無法進行有效的帳號管理，實務上，最常見或較正規的解法就是透過LDAP或資料庫來進行整合帳號整合。但在某些特殊場合，我們也會透過建立關連的方式來維護使用者帳號的一致性，不過這類方式的優點是易於實行，但缺點也是顯而易見，系統將會是疊床架物而難以維護，如果使用者願意接受，仍以統整在LDAP或資料庫中為優先推薦。
(2) 認證
一般的單一系統很少將認證與授權分開來討論，事實上他們是兩個動作，簡單的說認證是認定誰是誰，授權則是說明誰可以做什麼。這在跨系統服務中很重要，因為一般我們常採用單一認證及分系統授權的運作機制，如果觀念不正確或設計系統時不分開來，其結果就是糾纏在一起的單一簽入系統(SSO)，未來將難以或無法維護。常見的認證方式有已下幾種。
第一種 帳密認證
也是最常見的處理方式，透過帳密來進行認證。
第二種 憑證認證
這類方式更為嚴謹，後臺往往需要整合認證伺服器與LDAP(多數使用LDAP，其實資料庫也可以做到)，來進行使用者真實身份認證與系統帳號的關連檢核
第三種 網域伺服器整合
有些系統本身則是透過網域伺服器進行網路資源整合，如微軟的Windows Server 2003，其背後的運作原理則是透過Active Directory(AD)來進行管理，而AD其實也是遵循LDAP標準所開發的商業產品，在整合上類似LDAP的帳號整理原理，不過，為了要活用Domain Controller所發出的Token，在整合上要利用微軟所製定的函式庫會較為方便
(3) 授權
SSO的實作方式有很多的方法，這塊領域其實也已經有很多偉人走在前面了，大多情況下我們只要追隨就可以了，最常被運用的原理就是Kerobos所提倡的方式，簡單的說明如下
(1) Client輸入帳密
(2) Server端驗證帳密(或憑證)，若驗證通過，就產生一張有時限的Token1
(3) Server端將Token1發給Client端
(4) Client取得Token1後進入特定服務，並遞交Token1給服務
(5) 服務端將Token 1轉交給原發行端，確認Token1 是否合法
(6) 原發行端驗證Token1後，認定合法，透過發出Token2通知服務端該使用者合法身份
至於服務端該怎麼決定授權的範圍，在實作上有三種作法，
第一種作法
採用中央集權式的作法，由驗證端在Token2告之服務端其使用者權限
第二種作法
採用分權式作法，在Token2上面沒有告之服務授權的範圍，僅說明使用者身份為何，由服務自行授權
第三種作法
混合式做法，採用分層授權的作法，驗證端決定是否可以使用此服務，而服務端再決定其更細的功能項目。
理論上，第一種作法是最好的作法，因為只須要維持一份的資料就可以了，但實務上，第二及第三種作法反而最常被採用，因為常常需要整合的是已存在的Legacy System，其多半都有自身的權限設計了，如果採用第一種的作法就需要修改所有系統的權限設定，容易造成系統風險與成本的提高，有時甚至造成原系統維護者的抗議，惹來政治上的風暴。
Token 1的存續時間
另一個重要議題是，Token1的存續時間，剛剛已經提到，Token2必需由Token1驗證後產生，理論上，只要有Token1我們就可以完成單一簽入的任務，但基於安全的考量，Token1往往是有時限的，並且用過一次就丟了，在這種情況下，Token1的存續時間就很重要，在設計上，建議是在每一頁Page_Load的時候，都通知驗證端拉長Token 1的有效期限，不過，這樣的作法有時候會受到來自於已存系統維護者的反彈，因為他們修改幅度會變大，有時折衷的作法就是拉長預設的Token1存續時間，並且在首頁登入時通知驗證端再加長認定時間就可以了，例如每次30min，但相反的，安全的風險也加大了。
重要觀念說明: 代登入不等於單一登入
另一個容易被混淆的觀念是代登入與單一登入的差別，何為單一登入在前面已經說明了，那麼為什麼代登入不等於單一登入? 舉一個簡單的例子說明
(1) 使用者登入入口網後，系統將使用者帳號儲存愛Session中
(2) 使用點選其他網站服務，系統將儲存在Session中帳號送出
(3) 新點選的網站，收到使用者的帳號，進行權限驗證
(4) 驗證無誤後，進入該網站服務
看起來很類似單一登入，但我們將(2)拿出來仔細檢驗，就會發現其實這是透過AP的程式碼來達成的，像是用接力棒的方式來完成代登入，也就是說，同樣的運作設計需要分散在每一個可能的程式段落，在系統維護上將會造成極大的困擾，除此之外，如果透過 ”我的最愛” 等方式直接跳頁，很可能無法達成單一登入的效果。
2. 訊息傳遞安全
說完了使用者權限的安全，SOA跟一般系統相比，另一重要的議題就是，訊息傳遞安全，一般來說我們會分兩個層級的安全角度來看
(1) 網路層級
由於網路上的封包傳遞是類似在透明通道的方式進行，為了提高安全其中的一種方式，就是將訊息包在不透明的容器中，然後在透明的通道中行進，這裡指的不透明的容器，就是指網路封包的加密加簽，例如HTTPS/FTPS就是最常採用的一種方式，這類方式的好處是，由於訊息封包包在網路封包內，所以，不需要經由AP去完成，只需要在網路層進行安全加密就可以了，讓程式本身專心執行業務需求，而不要再去處理瑣碎的系統安全問題。
(2) 訊息層級
訊息層級，則是針對傳遞內容本身進行加密加簽的作業，其好處是，具有不可否認性及唯一性的優點，不過，此類作法往往涉及到非對稱式加密技巧，所需的開發成本較高，並且在加解密的過程中，容易衍生效能問題，除非是重要的電子公文，一般不會主動使用此方式進行。
在經驗上，如果是Intranet的內部服務串聯，除了登入時會使用HTTPS來確定帳密的安全外，在訊息的傳遞上，顯少會刻意去強調內部訊息的傳遞安全性。不過，若資料有向外傳遞的必要性，例如電子公文，則通常會透過訊息層級加密加簽的方式，以確認該電子文件的唯一性與不可否認性。
3. 服務使用安全
這裡所提的服務指的是網路上的各式服務，但並非所有人都可以使用所有的服務，例如，一般使用者可能就無法取得公司財務系統內的資料。這在設計上，就需要在服務的利用項目上進行安全控管，在實務上也有三種的方式來進行
(1) AP層級
此類方式，衍生自現行許多系統的作法，最簡單作法是透過設定IP address的方式來決定，什麼服務可以被什麼外部系統所呼叫，這類方式的好處是易於實作，但安全性則遠不如下述的另兩種方式，適用在內部系統的服務整合。
(2) User 層級
在傳遞的資料中，存有使用者的帳號資料(例如Token1)，而使用者資料可在ESB或被呼叫的服務中進行使用者權限的檢查，確認該使用者是否有權使用特定的服務。
(3) 資料 層級
這類做法是透過加密加簽的方式來確定資料與使用者的正確性，屬於最嚴謹的認定方式，但過去的經驗是覺得雖然嚴謹但是效能不好，比較適用到有對外服務的重要資料，如政府具有法律效力的電子公文。
留言列表
