2021年4月17日 星期六

透過持續改善縮短你的cycle time

底下這張圖,看起來頗有學問…
圖片來自MS Azure DevOps AZ-400-1
圖片來自MS Azure DevOps AZ-400-1

我們在上DevOps的課程時,第一件事就問同學:在這個大企業林立、變化迅速的時代,新創或台灣的小公司在充滿資源的全球大企業輾壓下,要如何存活?

John Boyd的OODA循環帶給我們一個契機,如果你有興趣,可以google一下OODA循環,在wiki百科中的描述如下:

OODA循環的理論,來自於美國空軍在韓戰中的經驗。 在韓戰中擔任戰鬥機飛行員的空軍上校約翰·博伊德(John Boyd)認為,美國空軍過於注重速度,在越戰的早期空戰中,這一點就已凸顯出來。而與之形成鮮明對比的是,過時的蘇聯製米格戰鬥機卻在戰場上如魚得水,原因是因為米格機相對容易操作。 在對於競爭型戰鬥機進行了一番詳細分析之後,博伊德的結論是,飛機在空戰中最關鍵的性能並非絕對速度,而是敏捷度。在混戰中反應能力最強的戰鬥機能夠繞到敵人身後,隨時準備置敵於死地。 博伊德將其想法總結形成「OODA理論」。

在如今真實世界的挑戰中也是,最關鍵的性能並非『絕對速度』,而是『敏捷度』。這是新創和科技公司在最近這20年屢屢戰勝的核心原因。即便大公司擁有更多的資源,但面對挑戰總是輸在自身遲緩的反應上…

因此,DevOps的核心工作,其實是『持續改善,並竭盡所能的縮短你的循環時間(Shorten your cycle time)』。

這些cycle time包含…你修復一個Bug所需要的時間(改善一個錯誤的時間)、你增加一個新功能所需要的時間(在市場上提供新服務的時間)、學習並應用一們新的技術所需要的時間…

而這些縮短且省下的時間,就是你持續改善的所得到的『價值(Value)』,也是企業贏的關鍵。你的『持續改善』(持續縮小cycle time)最終停留在哪一點,你企業(或個人)的限制(瓶頸)就在哪一點出現。
圖片來自MS Azure DevOps AZ-400-1
圖片來自MS Azure DevOps AZ-400-1

因此,DevOps追求的是持續改善、持續整合,透過不斷合併與測試,盡早發現缺陷,盡早改善,就是DevOps中CI(continuous integration)做的事情。

面對縮短cycle time的挑戰…

  • 你能多快修復一個bug?
  • 你能多快上版(當然得同時兼顧安全性與品質)?
  • 新功能能夠多快交付到用戶手上?
  • 新構想能夠多快在市場上開始實驗?

改善的瓶頸,決定了企業的瓶頸。持續改善,能讓你的進步與競爭力能夠持續延續…


相關課程:
https://www.studyhost.tw/NewCourses/ALM

2021年3月20日 星期六

asp.net 身分驗證類型與基本原理(一)

這一篇很特別,我們要來談談 asp.net (.net core) 的身分驗證類型與基本原理(架構)。

最近這幾年,你可以從網站上找到任何你想找的資訊,特別是程式碼片段,但我總是眼睜睜的看著學員或客戶,從莫名的網路上抄來一份代碼,試著崁入自己的程式,無奈就是怎麼塞都塞不進去,不然就是硬塞進去之後,運行起來不如預期。

原因很簡單,因為硬Copy過來別人寫的東西,我們往往可能根本不知道那段程式碼寫的是什麼,只能硬插,無從改起。

這種狀況這幾年看了不少,身分驗證的部分更加明顯,有同學在寫WebAPI,但卻想用登入畫面去驗證呼叫者身分(!?),有人明明在寫MVC,卻一直在研究怎麼用JWT Token登入…細問同學為什麼要這麼做? 答案總是很有意思。

所以,一直想寫篇文章,來釐清一下這些東西。

asp.net 網站的身分驗證(保存)類型

asp.net 不管是哪一個版本,不管是 .net framework 或是 .net core,本質上都是一樣的。大部分情境下(這世界總有特例,文章也總是有背景,我們討論的是『大部分』情境下,若有特例,請讀者自行轉換),伺服器端保留(維持、識別) 用戶身分的機制大概有底下幾種:

  1. asp.net的Session變數
  2. aps.net Cookies 驗證
  3. Token (最近好像很流行 JWT)

首先,你必須知道一個前提,所有的Web應用程式和網路上伺服器和用戶端(瀏覽器)之間的交互(資料傳遞、呼叫)行為,本質上都是無狀態的(stateless),也就是說,你不能假設伺服器端知道用戶是誰,或是伺服器端連續兩次的呼叫是不是由同一位用戶觸發的。

enter image description here

這點跟你的經驗可能不符,你會覺得,網站(伺服器端)知道你是誰啊?不然用戶幹嘛登入? 登入後伺服器端不就知道用戶是誰了嗎?

對,許多的網站都能夠登入,如果是無狀態,那登入怎麼實現的?

好,實現的方式大多是底下這樣,在伺服器端與用戶端溝通(互動)的過程中,會在 http message(大多是header)中,夾帶著一個記號,這個記號具有唯一性,每一個用戶都不同,這個記號隨著網頁每次的來回傳遞(或是WebAPI的被呼叫),被夾帶在訊息(http message)之間,因此可以讓伺服器端知道當前的用戶端是哪一位。(這個記號大多只是一組ID,用來讓伺服器端識別用戶端,而非在記號中直接存放用戶名稱)
enter image description here

不管你用前述三種的哪一種身分保存方式,本質上最終都有這樣的一個機制存在。而預設狀況下,要實現這樣的結果,最方便的實作就是Cookies。

所以,即便你用伺服器端Session保存資訊,預設狀況下,也會用到Cookies,作為伺服器端與用戶端之間的關聯(associate),否則伺服器端根本不知道這Session是屬於哪一個用戶的。

參考: https://stackoverflow.com/questions/2589823/do-session-use-cookies

使用Session保留用戶身分

好,那我們先來談Session。
就如同我們大家所知,asp.net 的Session變數是存放在伺服器端,可以在單一Domain & 單一用戶的狀況下,進行跨頁面存取。(Session可以跨頁面、但不能跨網站、不能跨用戶)

所以,古時候很多網站的身分保存機制,是製作一個有帳密輸入功能的登入網頁,當用戶輸入帳密後按下登入,成功驗證帳號密碼與資料庫中保存的相符之後,就把用戶的帳號(或email)存在某個Session變數中,然後就視為該用戶已經登入完畢,且由於該Session變數可以跨網頁存取,因此在頁面巡覽(切換,跳頁)的過程中,只要該Session沒有過期(Timeout),後端都可以將前端該用戶視為已登入,並取得該用戶的身分(email或帳號)。

在這種模式底下,檢查用戶身分的方法,就是在網頁的後端程式碼中檢查保存用戶身分的Session變數內的值,如果有值,則表示已登入,並可取得用戶身分。

但別忘了,這狀態可以work,骨子裡還是因為用到了Cookies。

最近我們不建議用Session作為身分驗證方式,因為難以實現附載平衡或是高可用性,Session實質上是儲存在伺服器端的記憶體中的,當伺服器端有多台伺服器時,不容易跨伺服器保存。雖然可以採用資料庫作為Session的儲存位置,並實現跨伺服器(Web Server)使用Session,但如此一來用Session的意義就不大了。(因為犧牲了速度,最終跟使用Cookies可能差不了多少)

使用Cookies驗證

asp.net 本來就有一個 Cookies 驗證(cookies authentication)機制,這個機制本質上背後的作法跟前面我們一開始說的模式也差不多,就是在伺服器端(Server)與用戶端(Browser)溝通的過程中,保留一個具有唯一性(unique)的 State Cookie,並且把這個狀態Cookie在每一次瀏覽器的呼叫(post/get/…)過程中,傳遞給伺服器端。這樣伺服器端就可以知道用戶是同一個,然後伺服器端把資料或HTML回傳給用戶端的時候,也把Cookie回傳給用戶端。所以,你會看到,asp.net的http訊息當中,常常會看到底下這段:
enter image description here

因此,你會看到實作了 cookies 驗證的 asp.net core 網站,在http訊息中會夾帶著上面這樣的『記號』。透過這個唯一值,伺服器端就可以得知用戶端的身分了。而這一整段是由 asp.net 框架自動完成,所以開發人員大多不用寫什麼Code,可以直接用 user.identity.name 取得登入者是誰,用戶的登入與登出也大多只需要一兩行程式碼就可以搞定,使用起來非常方便。

有興趣可以參考筆者的 github 上 .net core 的範例:
https://github.com/isdaviddong/dotnetCore-PureWebAppLogin
文章:
https://studyhost.blogspot.com/2021/03/cookieswebapi_1.html

安不安全?

到這邊我們先岔題一下,待會再來談 Token。

先說,Session有沒有比較安全? 因為很多人一開始以為 Session是完全儲存在伺服器端的,所以一定比較安全! 但事實是,Session 必須倚賴傳遞於用戶端與伺服器端之間的 Cookies,因此結果最後跟使用Cookies驗證的安全性大致差不了太多。

再來,Cookies是否容易被惡意複製或竊取? 答案是,不無可能,但有難度

我們擔心 Cookies 被複製的主要原因,是擔心用戶身分被他人偽造(冒用)。要討論這個,重點在,這個他人是誰? 他在哪裡? (為何這重要? 待會你就知道)

主要有兩種可能:
1.在網際網路(或區域網路)上
2.在你的電腦上

先討論在網際網路上,有沒有人能夠在網路上偷看或竊取你的Cookies 資料? 這部分有個關鍵,就是傳遞的過程中有沒有走 SSL 加密,也就是 https 的protocal,如果沒有,那你的傳遞資料基本上是透明的,網路上人人可看,也就沒有安全性可言。如果你的傳輸過程是走 https ,那『理論上』,只有『瀏覽器』和『伺服器』兩端可以『看懂』你的資料,路上的其它人(駭客、設備、路由器、網路線、分享器…)看到了也看不懂,不容易竄改或偽造。

再講另一種Cookies被複製或竊取、偽造的可能位置,就是『在你的電腦上』。倘若,Cookies最終被儲存到電腦上的某個位置(硬碟),那當然還是有被複製(或竊取)的可能。只是,這個可能性有多高? 而且哪邊是可能的漏洞?

要知到,所有的資訊都可能存在於幾個位置,像是記憶體、畫面、硬碟…記憶體內的資料相對難被竊取(因為大部分的應用程式有獨立的行程,不能共享記憶體)、螢幕上的東西只要拿手機拍照就好(沒事不要把機密資料攤在螢幕上)、硬碟內的東西也相對容易被偷(應用程式有機會可以讀取到別的應用程式儲存的檔案或資料),所以有些公司崇尚『資訊不落地』,敏感的東西不得隨意儲存,只能在記憶體內使用。所以Chrome瀏覽器的無痕模式,會在關閉後清除所有Cookies。

但其實,上述Cookies最有可能的漏洞的確是『瀏覽器』,因為網路傳輸的過程中,只有瀏覽器碰到該資料(其它過程都有SSL保護),使用無痕瀏覽器時,關閉了視窗Cookies也被清除,但倘若瀏覽器本身有問題(來路不明、或被瀏覽器外掛給駭了),那當然就沒啥安全性可言。

所以,亂裝瀏覽器外掛其實很危險。另外,瀏覽器是透過OS(作業系統)運行,如果作業系統本身被駭了,那當然也有極高的安全性疑慮,因為控制了作業系統就控制了一切,隨時可以偷看你的記憶體或硬碟。所以,所有的作業系統安全性更新,都應該第一時間安裝。

所以結論是,如果走 https 的網站,在使用安全無虞的瀏覽器,且作業系統也沒安全性疑慮的狀況下,cookies應當是安全且不易被『非法』複製的。

框一個非法,因為用戶還是可以合法地去檢視和複製cookies。

總的來說,如果你的瀏覽器有問題,或是作業系統有問題。那沒什麼好說的,任何上網或其他運作都有風險疑慮。所以資安的第一個前提,就是不能讓駭客以任何方式接觸到實體設備,如果不能確保這個,那沒任何資安可言。

但如果瀏覽器可以被信任(不是雜牌瀏覽器),又都走https通訊,用戶也謹慎的使用無痕瀏覽模式,那安全性算是相當高的。

公用電腦上使用瀏覽器,一定要使用無痕視窗

什麼是 token

接著我們談 token,你常常聽到的 JWT就是token的一種。token,翻成中文比較好的翻譯是『令牌』,古時候武裝劇裡面的『見令如見人』的那種令牌。

拿著令牌,多半意味著可以存取些什麼資源。因此,大多數Token的運作行為(發放和使用)類似底下這樣。

  1. 由管理資源的單位(網站或系統, 例如管Google Drive的Google)發一個Token
  2. 這個Token代表著某個用戶授予的某種授權(例如David授予某人或某系統存取David的Google Drive中的文件的權限)
  3. 因此發token時,Google必須經過該用戶確認(所以David必須輸入Google帳密,當然是在Google的網站上,帳密也無須給他人知道,一般這類Token中也不會包含帳密或email)
  4. token發出後,可以交給某個系統(或某人)
  5. 得到該Token的人(或系統),就可以拿著這個token,向管理資源的單位(例如Google)取得用戶授予的某些資料(就是有存取該用戶 Google Docs的權限)

enter image description here
Token最典型的用法是上面這樣。反正就是個『令牌』的概念。

第三方網站(或是App),在需要存取用戶的Google Drive時,就是依照上面的流程,引導用戶去Google網站完成驗證(輸入帳密,同意授予權限),待取得Google發送的Token(令牌),第三方網站(或App)拿著這個令牌,就有權限去Google網站(一般是透過呼叫API的方式)以用戶授予的權限做些(或取得些)什麼。整個流程就是這樣。

Token的使用場合?

因此,token大多是用來證明自己(應用程式、呼叫端、第三方網站)具有存取某些資源的權限。你常會看到,用戶使用某個App的時候,應用程式讓你連結到Google網站(大多走OAuth模式),讓你同意授予某些權限,App的這個動作就是在取得你授予的Token,取得後,應用程式會把該Token保留起來,以便於後續使用。

你可能會擔心,那該應用程式或第三方網站不就可以存取你的某些資源(例如Google Docs, Calendar…etc.)? 是的,正是如此,因此Token多半有時效性,可能是數天,也可能是一兩年,依照授權決定。那萬一Token外洩,撿到的人不就有可能用該App或第三方網站的身分來存取你的資源? 也沒錯,所以Token多半不會公開顯示,傳輸過程也必須透過加密(SSL),甚至儲存位置也要謹慎(最好別儲存)。

Token安不安全?

安不安全,就看你(第三方網站或App)怎麼使用!

Token的本質跟secret差不多,基本上都算是機密資料,不該公開,不能外洩,不應隨意儲存。最安全的使用方式是取得Token立即拿來用,用完就丟(刪除),不要儲存在任何地方,只停留在記憶體內,這樣當然最安全。

但如果有一個應用程式(或網站),一天到晚需要你重新登入Google帳密只為了取得新的Token,你一定會覺得很煩,所以大多應用程式取得Token之後,都會自行保存起來,能用多久就用多久(這意味著,只要Token沒失效,該應用程式就可以存取你的資源。你發了這Token,其實就意味著你信任該應用程式)。而該應用程式把Token存在哪裡,就成了關鍵。

理想的存放位置是後端DB或是更安全的環境,手機App取得Token之後,如果存放在App的storage是否安全? 網站取得Token後,如果放在 local storage是否安全? 這都是相對的,只要儲存了,就『相對』不安全。但如果不儲存(或是效期太短),需要使用時就得常常重新取得Token,一天到晚讓用戶重複輸入帳密,不僅麻煩,也不見得安全。

所以儲存是迫不得已的事,而儲存安不安全,跟前面的Cookies相同,只要OS和App本身不被駭,不會有其他程式碼有機會讀取到該App的資料,那基本上是安全的。

Token的用途

所以,Token主要的(原始的)用途就在授予某種權限,應用程式可以保存Token,無須知道用戶帳密,就可以拿著Token存取用戶授予的資源。這也是Google Docs、Calendar這類的資源常常可以安全的讓第三方應用程式或網站存取的原因。

除此之外,Token也可以被用來作為具有某種身分的象徵。例如前後端分離的SPA網站,當用戶驗證完帳號密碼之後,後端可以自己發一個Token給前端,前端取得該Token之後,就可以在未來呼叫後端的API時,把Token當作參數在http header中,傳遞給伺服器端,伺服器端的WebAPI可以檢視該Token是否有效是否到期,來決定是否允許前端呼叫。

而這種身分驗證方式採用的Token格式,近年來最常見的做法就是 JWT(JSON Web Token)。JWT是一種open source的Token格式,任何開發人員都可以自行依照該格式建立出一個Token,其格式包含三個部分,分別是:

  1. Header
  2. Payload
  3. Signature

我們暫且不討論它的技術細節,你可以在底下這個連結看到更多詳細的內容: https://en.wikipedia.org/wiki/JSON_Web_Token

如果你有興趣,可以用底下這個網站自己建立一個 JWT:
http://jwtbuilder.jamiekurtz.com/

然後用底下這個網站來解析(Decoded) JWT:
https://jwt.io/

你會發現,JTW中的Payload,可以包含登入者的身分資訊(或其他必要資料,因為不需要secret即可decoded,所以很方便作為用戶身分的保存與取得),且因為Signature有透過secret做Hash,則可用來讓token的發行者作為檢核之用,確保該token是自己發行的,不曾被竄改。

對於asp.net應用程式而言,一般來說,JWT有底下幾種典型用途:

  1. 前後端分離的SPA(Single Page Application)應用程式的身分保存(也就是無狀態下的身分維持機制)
  2. WebAPI呼叫時的身分驗證

上面這兩種作法的行為,其實都很類似前面一開始介紹的模式,用戶從前端輸入帳密,呼叫後端API驗證完身分之後,後端自行建立一個JWT(Token)發給前端。未來,前端(Browser上的JavaScript)有任何對後端(WebAPI)的呼叫,都使用這個Token作為身分識別(作法是夾帶在http header中)。

後端WebAPI取得這個Token之後,可以驗證該Token是否為自己所發(透過Signature),也可以得知用戶的身分(透過Payload)。如此一來,簡單的解決了SPA和WebAPI呼叫的身分驗證(身分抓取)問題。

這和Cookies驗證有何不同?

講到這邊,我真的覺得我寫太多了,一寫起來,文章像是自己有生命一樣停不來。不過,有了前面的基礎,我們開始可以討論一些問題了…

不知道你會不會聯想到一個問題,這樣JWT Token若在SPA網站上使用,跟前面的Cookies驗證有何不同?

你會發現。其實本質上是差不多的。身分驗證完畢之後,給前端發個記號(令牌),接著在前後端交互(WebAPI呼叫、或是頁面巡覽)的過程中,在http header中夾帶著這個記號(令牌),讓伺服器端可以驗證,並且達到識別且維持身分的效果。差別只在 Cookies驗證中採用的是Cookies,而JWT則是自己發的Token。

所以,傳統的非SPA網站,例如 asp.net MVC(含WebForm)或是 .net core的MVC或Razor Page,是否需要以JWT做身分識別? 從我的角度來說,我自己覺得其實不需要,採用內建的 Cookie Authentication就可以了(輕鬆方便)。若採用JWT反而麻煩,不僅發token和解析token與維持身分的code都要自己撰寫,頁面切換(submit)的過程中,要保存token不落地(不儲存)也頗煩人,最後還是得把JWT(Token)存在localstorage或cookies中,結果跟使用cookie authentication本質上沒啥兩樣。

SPA的身分驗證機制

但SPA(Single-Page Application)呢? SPA則毫無疑義,使用JWT方便得多,而且由於SPA大多徹底的實踐了前後端分離,因此換頁(submit)的機會少,大多前後端交互都採用AJAX呼叫,所以透過JWT保存(維持)身分、呼叫後端API都很方便。因為前端不太需要換頁,所以JWT可以安全的保存在記憶體中就好,無須寫入Local Storage,瀏覽器關掉就失效,下次開啟瀏覽器重新登入即可,這樣才能有高安全性,否則隨意儲存JWT(Token)其實風險可能更高。

WebAPI的身分驗證

那WebAPI的身分驗證呢?

我自己覺得使用Cookies驗證或JWT(Token)的形式其實都可以,因為兩種都能輕易達成。如果我的網站本質上是MVC或RazorPage,那我會選用 Cookies驗證。但如果我的網站是SPA,那我會選擇JWT,總之跟著網站(網頁)的行為就好,簡單方便又具有一致性,無需特別做另一套。但如果你沒有具有網頁的網站,只是單純做WebAPI(給前端或其他應用程式呼叫),則隨意,用哪一種都可以。但如果用戶端只有手機,或是用戶端有可能跨網域,那我會選擇JWT,因為手機或Web/Desktop應用程式要模擬Cookies的保存必須實作一個 Cookies Container,相對麻煩一些。

總結

到這邊,你大概知道了 ASP.NET Web應用程式(不管是 .net core或是 .net framework,不管是MVC或Razor Page或SPA)進行身分保存(維持)與實現登入功能的原理。我們後面接著要來討論,在這個原理底下,Web應用程式的SSO(Single-Sign On)是如何實現的?

未完,待續

參考課程:https://www.studyhost.tw/NewCourses/aspnetcoreauth

.net core 採用 Cookie驗證下的用戶身分抓取

enter image description here

關於 .net core的登入與身分驗證方式

前情提要…

前幾天,我們示範了如何在 .net core 環境下,使用 cookie-based authentication 來實現登入與身分驗證功能。這個做法是從 .net framework以來就有的,也是延續到 .net core 最簡單且輕量級的身分驗證(登入)方式。

整個作法的影片在底下:

https://youtu.be/ag9vQX9GAPs

當然,ASP.NET Core和 ASP.NET Framework 一樣,另外還有一整套 ASP.NET Core Identity機制,這套機制非常完整,除了基本的身分驗證,還包含權限管理、角色(Role)、Token、電子郵件驗證、忘記密碼…etc. 功能繁多。但當然也笨重很多。對於資料庫和身分管理邏輯也有一定程度的相依性。

也因此,我自己比較喜歡 cookie-based authentication 的簡單方法。

而採用了 cookie-based authentication 後的網站,可以透過 C# 後端程式碼,以很簡單的方式透過底下這樣的指令:

User.Identity.Name

就可以抓取到當前登入的用戶名稱。詳細的做法,在上面的影片中我們已經初步的介紹了。

接著,有讀者問到了OAuth的驗證整合,最常見的就是Google 登入。Google登入是什麼呢? 你會看到最近很多網站,都採用Google帳密登入,而非使用網站自己的帳密(也或許是兩者同時)。

所謂的Google 登入驗證,是一種SSO(Single-Sign On)登入機制,採用的其實是一套業界標準的OAuth機制,除了Google以外,Microsoft、Twitter、LINE都有利用這個標準做出了自己的登入功能。相關的說明您可以參考筆者之前的介紹。採用這個機制時,網站不需要知道用戶的Google帳密,只需要把身分驗證這一段,丟給Google去作,作完後把結果以Token回傳給網站。

透過Google SSO登入之後,我們可以取得用戶的Token,藉由Token取得用戶的身分(email),接著,再利用前面介紹過的cookie-based authentication,把取得的 email 視為用戶已登入的帳號,以該帳號完成用戶登入,如此一來,就在 .net core的 WebApp(Razor Page)實現了 Google SSO 搭配cookie-based authentication的身分驗證功能,這部分可以參考底下這個Lab,你會看到整個開發流程,以及實作出來的結果:
https://github.com/isdaviddong/HOL-DotNetCore/blob/master/Auth/使用 .net core 搭配 Google SSO(Single-Sing-On).md

讀者請留意,你必須先申請Google SSO所需相關資訊,像是Client_id, Client_Secret,才能夠實作上面這個Lab

WebAPI怎麼辦呢?

但接著,又有另一位讀者問到另一個問題,那如果我要搭配WebAPI,該如何作呢?

嚴格來說,WebAPI中要抓取用戶身分,其實跟Google SSO/OAuth無關,純粹就是cookie-based authentication得延伸,只是剛好我們先使用了Google SSO作為用戶的身分而已。

因此,我又作了Github上的這個範例:
https://github.com/isdaviddong/dotnetCoreWebAppGoogleSSOWithWebAPI/
這是一個razor page + Web API的範例,登入採用Google SSO,完成後以cookie-base的方式保存身分的範例。

但請看其中的WebAPI:
https://github.com/isdaviddong/dotnetCoreWebAppGoogleSSOWithWebAPI/blob/main/ValuesController.cs

你會發現,一但身分保存之後,在WebAPI中一樣直接透過

User.Identity.Name

就可以抓取到用戶身分,一個簡單的WebAPI程式碼如下(11行):

就這樣,不管你在 Razor Page, MVC, WebAPI都可以輕鬆的抓取當前呼叫的用戶身分。

使用 cookie-based authentication 這個架構很簡單漂亮,這讓後端C#中的程式碼(不管是MVC, Razor Page, WebAPI),都很容易的可以得知當前的用戶是誰。

如果你作的是一個企業內的商業應用程式,或是一個B2C或B2B的網站,那透過這樣的模式,在前端呼叫後端API時,不需要額外採用Token方式去驗證用戶身分,可以大幅降低開發時間,同時確保API被呼叫的安全性(可以輕鬆在API中檢查用戶身分)。

如果你採用前後端分離的架構,前端的開發框架(例如Vue),想要呼叫後端的WebAPI時,也可以透過這樣的方式,後端的C# Code自然而然能夠得知用戶身分,只有一個前提,前端必須在同一個domain。

那如果,前端是手機或另一個domain,要支援跨domain的身分驗證呢?

那就是另一個故事了…改天,再找機會繼續跟大家說明。

參考文件

A> Use cookie authentication without ASP.NET Core Identity

https://docs.microsoft.com/en-us/aspnet/core/security/authentication/cookie?view=aspnetcore-5.0

B> Introduction to Identity on ASP.NET Core

https://docs.microsoft.com/zh-tw/aspnet/core/security/authentication/identity?view=aspnetcore-5.0&tabs=visual-studio

相關課程:

https://www.studyhost.tw/NewCourses/aspnetcoreauth
https://www.studyhost.tw/NewCourses/Architecture

2021年1月15日 星期五

透過容器化使用LUIS在地端進行語意分析

透過容器化使用LUIS在地端進行語意分析

enter image description here

應該大家都知道,微軟從幾年前開始,推出了一系列的AI服務,稱為Cognitive Services,內容包含可以識別人臉、辨識圖片內容的電腦視覺,可以即時聽寫(語音轉文字)或輸出(文字轉語音)的Speech API,可以透過類神經網路翻譯的Translator API,還有可以讓chat bot認得用戶輸入的文字的LUIS與QnA…等。

這些服務在雲端上固然方便好用,但每次上課都會有學員問到,可不可以把模型匯出然後在on-premise環境做辨識?

一般會有這種需求不外乎兩個理由,其一是速度,另一個更重要的則是安全性,因為客戶往往不希望要辨識的圖像或文字透過網際網路被傳遞到遠端的伺服器中。

可以嗎? 是的。現在,透過容器化技術,你可以這麼做了。
如今大部分的cognitive services都開始支援容器化的應用方式。我們可以從雲端下載LUIS run-time的image,然後把在雲端上訓練好的模型下載後,透過Container技術在客戶端(用戶端)在on-premise環境做辨識。

怎麼做呢? 其實很簡單。

首先,透過docker command下載雲端上的LUIS run-time(如果在windows上使用,必須安裝好docker desktop):
enter link description here

完成後,從https://www.luis.ai/網站上把訓練好的luis模型也下載下來:
enter link description here

你應該會下載到一個.gz檔案。
接著建立兩個資料夾,分別是 C:\input 與 C:\output ,用別的路徑當然也可以,後面的docker run指令配合著修改即可。

把剛才下在好的.gz檔案放入 input 資料價,請注意如果需要時要調整檔名,檔名格式為 LUISAppID_PRODUCTION.gz :
enter link description here

上述都準備完成後,請執行剛才下載的 docker image:
enter image description here

上面docker run指令的格式為:

docker run --rm -it -p 127.0.0.1:5000:5000 --memory 4g --cpus 2 `  
--mount type=bind,src=c:\input,target=/input `  
--mount type=bind,src=c:\output,target=/output `  
mcr.microsoft.com/azure-cognitive-services/luis:latest `  
Eula=accept `  
Billing=https://XXXXXXXXX.cognitiveservices.azure.com `  
ApiKey=78XXXXXXXXXXXXXXX21

其中的billing可設為你的Luis服務的endpoint,ApiKey當然是你的LUIS服務的Key。

你會發現,透過這樣的執行後,LUIS Container被執行了起來,我們可以在Localhost:5000看到LUIS服務了:
enter image description here

而辨識的API,也可以從localhost呼叫到了:
enter image description here

很讚吧。
感謝Docker感謝Container,讓一切變得如此簡單。

ref:
https://docs.microsoft.com/zh-tw/azure/cognitive-services/luis/luis-container-howto?tabs=v3

2020年12月11日 星期五

WebApp如何安全的存放機密資訊

WebApp如何安全的存放機密資訊

每一個重要的應用程式裡面都有機密資訊,從資料庫的連線字串,到後台admin的帳號密碼,這些大大小小的機密資訊,常常被開發人員存放在source code的某處…咦? 等等…

對,你應該有所警覺,這些資訊怎麼能存放在程式碼裡呢? 這顯然不夠安全啊。但…直到上周,我在上課的時候,還有學員依舊把連線字串和帳密寫死在程式碼中😮。

那你說,好吧,不寫在程式碼『裡面』,那我獨立寫在一個檔案裡面好了,在 .net 的世界裡,這就是 web.config或是 appsettings.json,但…這樣就安全了嗎?

只能說,『相對』安全了點,但還是不夠安全。

關鍵在於,誰能(或誰該)經手這些機密資訊? 早期的概念是把開發和維運團隊切開,讓開發人員無法得知最終的帳密,讓維運的人無法得知程式碼的內容,這樣,除非這兩個人同時被綁架(或彼此串通),不然企業的機密資訊還是可以得到保障。有點像是出納和會計不能是同一個人的道理。

這種保護是,不讓『某一個人』知道所有的資訊。只能說相對安全,並非絕對安全,因為經手機密資訊的人還是太多了。安全的定義是,不該知道的人,就不要知道。

因此,更好的方式是,讓機密資訊只有單一一個安全存放點,且由單一的某一個人寫入。並且,在取用的過程中維持『不落地』。所謂的不落地,就是不儲存在任何地方。簡單的說,就是需要使用時(例如建立資料庫連線),從安全的存放點取出(帳密),然後就保存在記憶體中,永遠不寫入任何的檔案、資料庫、硬碟…等儲存體。

真能夠實現這件事情嗎? 可以的。

微軟在Azure雲端上,有一個專門提供存放機密資料的儲存庫,稱為Key Vault(金鑰儲存庫),管理人員可以把機密資訊(例如admin的帳號密碼、資料庫的連線帳密…etc.),存放在這個Key Vault中,然後在WebApp的原始程式碼(檔案)中,就不要再存放這些資訊了。當WebApp需要使用的時候,直接問Key Vault拿就可以了:
enter image description here
這樣還有一個莫大的好處,管理人員可以隨時rotate(滾動轉換)帳密資訊,無須開發或維運人員經手。

由於Key Vault是被重重大鎖給保障的(採用高安全性的加密機制),因此可以說是固若金湯,安全無庸置疑…等…等等,不對啊,那我們的WebApp在存取KeyVault的時候,不是也會有帳密或連線字串嗎? 那這連線字串要放哪? 另一個KeyValut嗎??? 😛

如果存取KeyValue的帳密或連線字串,還是放在web.config或是AppSettings.json裡面,那這一切豈不都是白搭?

萬一 web.config 或 AppSettings.json被竊取,機密資訊不是被駭客整碗捧去? 原本只是損失個db連線字串,現在是損失整個KeyVault,豈不更慘?

所以關鍵來了,如果有一個方法,可以不用帳密就能讓WebApp『安全的』存取KeyValue,那不就解決了所有問題? 能嗎? 可以的。

由於WebApp和KeyValue都是Azure管理的,因此,我們可以設定KeyValue『信任』該WebApp,讓該WebApp存取KeyVault中的特定機密資料。只要設定完成,未來WebApp內的程式碼,跟KeyVaule拿資料的時候,就無需帳密驗證(其實不是沒有驗證,而是由Azure自行做驗證),開發人員不需要把KeyVault的存取連線字串或權限放置在WebApp的appsetting.json或任何地方,如此一來,機密資料的存取流程就安全無懈可擊了。

如何讓WebApp被KeyVault信任?
首先,請在Azure上建立該WebApp的身分識別:
enter image description here
這個動作會讓該WebApp在AAD上被註冊,你會得到一個物件識別碼,請取得該物件識別碼,然後到KeyVault的存取原則設定:enter image description here

請新增存取原則,出現底下畫面後,設定服務主體為剛才紀錄的WebApp 服務主體物件識別碼,並提供它具有存取該 secret (帳密)的權限:
enter image description here

完成後,你會發現神奇的事情發生了,該WebApp存取KeyVault中的該機密資訊時,是不需要連線字串或帳密的(類似底下這樣):
enter image description here

而WebApp取得機密資訊後,只要沒有儲存在任何儲存體上,就沒有外洩的可能(應該說外洩可能極低,除非記憶體被動態竊取)。如此一來,從KeyVault取得的機密資訊的流程不僅安全,也不須將機密存放在KeyVault以外的任何地方,達成機密資訊『不落地』的效果,這才是真正的高安全性應用程式開發。😎

2020年10月28日 星期三

Azure DevOps in Action - 如何避免開源套件的使用風險

enter image description here
近代軟體開發,不管是使用哪一種語言,幾乎都一定會使用到套件(Package),套件的使用都有著非常重大的意義。套件不只是讓開發變的更方便,套件的版本管理,能夠讓專案之間的相依性被有效管控,避免dependency hell的發生。

所以各大開發語言,不管是node.js、python、Java…都有自己的套件庫,微軟的.net當然也是,nuget就是.net開發人員的標準套件庫。如今,使用套件庫上的組件來開發企業內的專案,已經是理所當然的習慣了。

套件庫的使用風險

然而,使用套件並非100%毫無風險,由於開源軟體的觀念盛行,這個時代任何人都可以將自己開發的套件貢獻上nuget讓大家使用,雖然開發社群與nuget站台會針對有潛在或惡意風險的套件提出警訊,但由於這些資訊並非即時提供,且有可能因為開發人員的疏忽而沒有被發現,導致你的專案使用到有品質不佳,或是有安全疑慮的套件。

除此之外,套件還有許可授權的問題,並非每一個套件使用上都是毫無代價的,雖然nuget會要求套件開發人員具體標明套件的使用授權許可,但倘若開發人員不察,使用到一些並非可以免費使用的套件,或是使用到了標註為GPL的套件,那你依賴該套件開發的專案,也會被要求開源,這對於公司來說,可能會造成一場災難…

在CI Pipeline中掃描套件

因此,為了避免軟體開發人員一時疏忽,CI Pipeline有必要針對軟體套件的使用作一些掃描和檢查。而WhiteSourceBolt就是這樣的一套免費工具。

你可以在Azure DevOps Pipeline中,加入WhiteSourceBolt這個task,就可以輕易的掃描整個專案中使用的套件:
enter image description here

呈現出的報表如下:
enter image description here

你會發現,報表中清楚的告訴我們,哪些套件是高風險的,並且原因為何(上圖A)。如果你的專案有紅色高風險套件,強烈建議你要立即著手處裡(升級版本或尋找替代套件)。

要在Azure DevOps中啟用WhiteSourceBolt非常簡單,只需要為你的組織安裝Azure DevOps Marketplace中的外掛:
enter image description here

下載位置位於:
https://marketplace.visualstudio.com/items?itemName=whitesource.ws-bolt

安裝好之後,你重新進入Azure DevOps,可以看到在Pipeline選單下,出現了WhiteSourceBolt:
enter image description here

請點選進去,輸入你的聯絡方式註冊後即可使用。

接著,請進入Pipeline,在其中加入WhiteSourceBolt task,並且設定working directory:
enter image description here

完成之後,重新觸發運行pipeline,完成後即可看到報表囉:
enter image description here

幾個小小的動作,讓專案免於套件使用的風險,非常划得來吧。


本文摘錄自『Azure DevOps敏捷開發與專案管理實戰

2020年10月24日 星期六

使用IoC與DI有何意義? (三) 在 Console 程式中使用DI

這一篇的重點在介紹,如何在Console App中使用DI,但我們的重點卻不是 Console,而是 “使用DI”。

看完前面兩篇,你應該要想到一個問題,如果PageModel或MVC的Controller,被呼叫的時候,.net core的DI服務會自動幫我們把Startup.cs中指定好的類別實作,自動注入PageModel(或Controller),那Console中的Main()也會嗎?

好比說,如果我把程式寫成底下這樣:
https://gist.github.com/isdaviddong/5faad4066919b4e5e72ae85621d021c6

我在Main()中能夠讀到 _SalaryFormula 的值嗎? 猜猜看?



答案是===> 不會。

原因很簡單,因為Console App的進入點是靜態的 Main()函式,它根本就是一切的源頭,是應用程式被Launch起來的時候,最最最開始的入口,根本不會有人去幫你 run 上面 5-8行的建構子,所以理所當然的也沒有注入這回事。

那…為何 PageModel可以? 為何MVC的Controller可以? 原因也不難,因為當用戶點選(或連結到)某一個頁面(或某一個Routing)的時候,該頁面(PageModel或Controller)所觸發的那隻程式(Onget() 或 Action),根本就不是整個程式的進入點。它(頁面)是"被"人家執行的。這個執行者不是用戶,是由 asp.net 的框架本身host的。

其實,整個 .net 應用程式的入口一直都是 Program.cs。

請看底下這個MVC Web應用程式的Program.cs:
enter image description here
事實上,Program.cs才是一切程式的進入點,而上面的Host,則是幫我們運行(Launch)起 asp,net web應用程式的背後推手。(未來有空我們再談這個類別)

一直以來,是有一個host幫我們承載每一個頁面的。當asp.net的某個頁面被呼叫,每一個controller被觸發,都不是該class被用戶主動觸發,而是『被』呼叫,被誰呼叫呢? 就是框架本身。正確的流程應該是,某個頁面(或說網址)被呼叫到時,asp.net框架中的底層(middleware, routing…etc.)得知該request,接收該http request的各種參數之後,幫我們new出我們所寫的程式碼(類別),然後把相關參數(像是QueryString, 或是http body…etc.)轉成parameters傳遞給我們的Action或Page。

這也是 asp.net MVC一堆預設的約定(慣例)的原因(的來源)

而我們一直說,DI被作為服務納入 asp.net core框架中成為內建機制的一部分,因此框架在幫我們呼叫(觸發)某一個頁面的時候,就順手(偷偷的)把我們想要注入的執行個體透過建構子的方式傳入,造就了這整個 DI"服務" 的誕生,就如同我們底下這段程式:
enter image description here
上圖中的PageModel,之所以可以實現DI,因為該頁面被(框架)呼叫時,由asp.net core框架幫我們new這個頁面的執行個體(這時當然會運行到該類別的建構子),然後框架順手幫我們把我們在Startup.cs中指定好的(適用於HR.ISalaryFormula)類別執行個體給注入(填入)建構子中作為參數,來實現所謂的DI注入服務,然後你在程式碼中就可以光明正大的使用了。

好了,到這邊你大概了解DI的原理了,那回頭看Console App大概也就明白了,因為Console App的Program.cs根本就是一切的起點,在這個起點中,根本沒有所謂的 asp.net core框架、也沒有host,所以沒人可以幫我們的main()實現注入這回事…

真正實現DI服務的是…?

所以要實現注入在Console App中的話,我們必須自己建立這個Host。這時,有一個現成的機制很好用,就是 ServiceCollection,請看底下這段code:
enter image description here
這是一段console App,不過請不要誤會了,它長的像是Main()但不是Main(),你可以說它是仿的main(),因為它的類別名稱是 MainApp(而非Program),且其中的Method Main()並非靜態。

上面這一段寫起來就很像是前面我們寫在 MVC Controller或是PageModel裡面的建構子,對吧。

並且,它能夠執行出我們想要的結果:
enter image description here

但請注意了,它並不是主程式(應該說它不是程式碼的進入點),我們的主程式其實依舊位於Program.cs中的這個main()靜態方法:
enter image description here

真正去 new出 MainApp這個類別的執行個體,並且調用MainApp中的Main()方法的是上圖中的第43行。簡單的說就是,這一行程式碼"幫你"建立(new)並執行了MainApp.Main()這個方法。

而33,35分別註冊了依賴注入所需要的型別參考。也因為是43行"幫你"執行的,所以它在幫你執行的時候,可以順手把你需要(定義過的)的依賴類別給注入(填入)MainApp的建構子當中,以至於所謂的DI服務可以實現。將來要換其他的公式時候,只須把35行改為37行這樣的寫法即可抽換。

再次提醒,其實是可以透過設定來抽換,不一定必須寫成程式碼。

這才是整個DI服務具體的實現方式。

結論

有沒有發現,DI之所以成為服務,是因為有人幫你做了許多事情。框架幫你做了,ServiceCollection幫你做了,所以我們才說,它(DI)在.net core中已成為了一種"服務(功能)",被納入到框架當中。那…我們可以自己做嗎?當然也行,具體的實現方式其實不難,如果只是要一個最簡單的實踐,其實只需要透過reflection機制就可以了。

好,這一段先到這邊,我們後面要準備來介紹更重要的內容…
source code :
https://github.com/isdaviddong/DotNetCoreConsoleDIServicesExample


本文內容來自於『團隊開發與架構設計實務』課程,我們最近要開課囉,依照過去經驗這門課幾乎都是秒殺,如果你需要預先保留席次,請點選這裡登記唷。

若您要詢問問題,或是需要即時取得更多相關訊息,可按這裡加入FB專頁。
若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

熱門文章