新一代身份驗證機制 - Windows Card Space

新一代身份驗證機制 - Windows Card Space
<SLIDETITLE INCLUDE=7>Windows Server 2008 應用程式相容性</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE></KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> Hello and Welcome to this Microsoft TechNet session on {insert session title}. My name is {insert name} </SLIDESCRIPT> <SLIDETRANSITION> <TRANSITION LENGTH=7>Let us start this session by going into more detail on exactly what we will be covering.</TRANSITION> </SLIDETRANSITION> <COMMENT></COMMENT> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION> 曹祖聖台灣微軟資深講師 MCP, MCP+I, MCSA, MCSE,MCDBA, MCAD, MCSD, MCT, MVP

大綱 Web 應用程式身份驗證所面臨的問題過去的身份驗證機制什麼是 CardSpace ? CardSpace 的運作機制各種應用方式
12/7/2018 4:34 AM 大綱 Web 應用程式身份驗證所面臨的問題過去的身份驗證機制什麼是 CardSpace ? CardSpace 的運作機制各種應用方式登入頁面的改變 © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Server 2008 and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

身份識別上面臨的問題 25% 不瀏覽 22% 不購買 Internet 太危險了 ! 企業面臨管理大量身份識別資料的問題
小偷、身份偽造、釣魚網站 … username + password 的保護太弱企業面臨管理大量身份識別資料的問題 <To keep the phishing numbers up-to-date go to open the PDF and cut and paste the latest chart> The Internet is more useful than it’s ever been (Web 2.0, blogs, mash-ups, Live, …) and yet according to Gartner 22% of online purchasers have stopped online purchasing and 25% have reduced their online purchases. Why? Because the Internet is a dangerous place and there is nothing to protect consumers: the Internet is a wonderful thing but it was designed without an Identity layer. It’s for that reason that we have increasing levels of organized crime stealing our digital identities – this is not a bunch of script kiddies having fun. Harvard did a study and found that “Good phishing sites fooled 90% of participants”. This is not really surprising – you probably know someone who has fallen for this. Someone in the CardSpace product group lost money from their PayPal account and this is an identity expert so what hope is there for the rest of us? At the same time, way we typically identify ourselves online is using usernames and passwords and everyone in this room is probably suffering from password fatigue from having to remember them all! In fact, there are 3 methods of coping: use one password everywhere, use 5-10 passwords, have a unique password for each site but write them on Post-Its (or .XLS) – at least someone needs physical access to discover your password! The Enterprise has too many identity solutions, the web has none! There is no consistent, secure way to represent identity “Silo hell” - myriad incompatible identity silos Tons of time and money spent just on plumbing (hundreds of) systems together And regulatory pressure: SOX, FDIC, … 22% 不購買 25% 不瀏覽

我們需要什麼 ? 簡單、一致、安全的身份識別系統任何人在任何地點都可以使用讓使用者可以 100% 控管自己的身份資料
 移除系統之間身份識別障礙 Simple, consistent, secure way to represent identity Usable by all and for all - consumers, enterprises, ISVs, existing systems, future systems Open, non-proprietary, inclusive Works with scenarios and systems Puts users in control of their identity Protecting their privacy Helping them do the right thing Puts the user at the centre No rip and replace of existing systems, works with systems, breathing new life into them by connecting them to the world

IIS 7.0 存取控制檢查來源 IP 檢查使用者檢查伺服器存取權限檢查共用權限 (如果是 UNC 路徑) 檢查 NTFS 權限

身份驗證介紹 IIS 中的身份驗證要求進入 IIS IIS 將要求轉送到匿名 provider: Server Core
IIS 建立路徑 (w3svc/1/root) 並且檢查匿名證是否有啓用是: 提供路徑與 Anon.users token 給 authorization manager 否: IIS 將路徑交給其它每一個 provider，檢查該路徑是否啓用該 provider 提供的驗證每一個有啓用的 provider 檢查查使用者身份之後，會回傳適當的表頭給 IIS 匿名 Server Core 基本 Kerberos NTLM 摘要

Request received by IIS
Authentication Providers Slide Title: How Authentication Works on IIS 6.0 Keywords: Key Message: Slide Builds: 0 Slide Script: If anonymous access is not enabled for that path, IIS will pass the path to each of the other authentication providers to determine if that authentication provider has been enabled for the URL. This is so we can build a www dash authenticate header to send to the client so that it can know what authentication types are enabled for our page. The client can then determine which type is best for it to use. Slide Transition: Now that we understand a little of how IIS 6.0 works to authenticate incoming requests, let’s revisit our agenda. Slide Comment: Additional Information: IIS Server Core Anonymous Basic Kerberos NTLM Digest Passport 9

匿名驗證流程 IIS 伺服器 Web 瀏覽器 default.htm Client 10
Slide Title: Anonymous Authentication Keywords: Key Message: Slide Builds: 0 Slide Script: …and return it to the requesting browser. However, if the default.htm page is not enabled for anonymous authentication, and we mentioned this briefly already, IIS will compose a www dash authenticate header that contains the authentication methods the page is configured for and return it to the browser in a 401 error code response. So this looks simple and, in theory, it is. However, there are a few complications in anonymous authentication that we need to cover. Slide Transition: Let’s start by going over the IUSR account. Slide Comment: Additional Information: IIS 伺服器 Web 瀏覽器 default.htm 10

匿名驗證帳號匿名帳號: IUSR_[電腦名稱] IIS Sub-authentication
12/7/2018 4:34 AM 匿名驗證帳號匿名帳號: IUSR_[電腦名稱] IIS 安裝時建立，並加入 Guests 系統群組請注意套用到 Guests 的自訂原則預設狀況下，IUSR 帳號被授予所有資料夾的讀取權限 IUSR 帳號也使用在 FTP 伺服器的匿名驗證上 IIS Sub-authentication 避免密碼同步的問題 Define IIS Subauthentication Be aware of policies that are applied to the Guests group © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

基本驗證流程 401 Error IIS 伺服器 Base64 編碼的使用者名稱和密碼 Web 瀏覽器 default.htm 12
Slide Title: What is Basic Authentication? Keywords: Key Message: Slide Builds: 0 Slide Script: When the user has entered his or her credentials, the browser Base64 encodes them and sends them back to IIS. Once IIS authenticates the user and verifies that he or she is authorized to view default.htm, the page’s content is sent to the browser. Slide Transition: Now that we know the process by which basic authentication works, let’s take a look at some of its advantages. Slide Comment: Additional Information: Base64 編碼的使用者名稱和密碼 IIS 伺服器 Web 瀏覽器 default.htm 12

基本驗證使用 Base64 編碼來傳送密碼優點缺點 RFC 相容 (RFC 2617) 支援透過 Web Proxy 瀏覽器支援廣泛
如果配合 SSL，是很好的驗證方式缺點使用者需要輸入 Windows 帳號密碼直接傳送，如果沒有 SSL 配合，非常不安全

整合式 Windows 驗證也可以只用 NTLM，但不能只用 Kerberos 兩者都不支援 Web Proxy 要求 Negotiate
首先試試接下來再試 Kerberos NTLM 也可以只用 NTLM，但不能只用 Kerberos 兩者都不支援 Web Proxy

整合式 Windows 驗證 MetaBase 屬性: AuthNTLM
如果同時啓用基本驗證和整合式 Windows 驗證，Internet Explorer 會使用整合式 Windows 驗證 NTAuthenticationProviders 屬性: Negotiate,NTLM NTLM NTAuthenticationProviders 沒有任何管理介面，必須使用 adsutil.vbs 工具或 Metabase Explorer 來修改

NTLM 的行為連線導向驗證對話方塊 NTLM 如何使用 Domain \ Username \ Password
每個要求永遠使用相同連線必須啓動 HTTP Keep-Alives 功能驗證對話方塊 NTLM, 預設不會顯示如果原本要求傳回錯誤，則會顯示對話方塊 NTLM 如何使用 Domain \ Username \ Password Domain 和 Username 永遠會在 client 與 server 之間分享 Password 則不會，會使用密碼的雜湊碼驗證標頭中會包含: Domain \ Username \ HashedPassword NTLM over the internet works reliably *IF* and only if secured with SSL

NTLM 的安全性駭客無法透過封包擷取，來得知密碼的雜湊演算法
如果連線斷掉、被修改 (透過 Web Proxy)，那麼 NTLM 就會失敗 NTLM 版本 Lan Manager – Windows 95 NTLM v1 – NT 4.0 NTLM v2 – Windows 2000 / 2003

NTLM 的驗證過程 Get /Default.HTM Get /Default.HTM w/ AuthNTLM Client
Get /Default.HTM w/ AuthNTLM Hashed IIS Server 401 – Access Denied Client 401 – WWW Auth: NTLM 200 - OK IIS Server

Kerberos 為什麼要另外建立出一個驗證協定這是全新的協定嗎 ? NTLM 的限制
NTLM Tokens 無法被委派 NTLM 只支援 Windows 平台 NTLM 不支援其它瀏覽器這是全新的協定嗎 ? 不是，它只是一個轉換介面，根據用戶端的要求來決定要使用 Kerberos 或 NTLM

Kerberos 用戶端: Internet Explorer
伺服端: IIS Server (Active Directory 網域成員) Active Directory: Key Distribution Center (KDC) Ticket Granting Service: 負責發出所有的 tickets (aka tokens)

Kerberos 運作機制 IIS Server IIS 啓動後，當伺服器跟 KDC 做驗證成功後，會取得 ticket
Domain Controller (KDC) Ticket Granting Services

Kerberos 運作機制 Domain Controller (KDC) IIS Server 用戶端使用匿名身份連線至 IIS
IIS 回傳 401 錯誤，加上 WWWAuth 標頭，要求進行協調用戶端向 KDC 要求存取 IIS 的的 ticket 如果 IIS 是 AD 成員， KDC 會發出 shared key Shared 用戶端使用這支 shared key 來建立雜湊碼，並且傳送到 IIS IIS 使用 shared key 來檢查密碼是否正確 IIS Server

摘要式驗證流程網域控制站 IIS 伺服器 Active Directory 資料庫 Web 瀏覽器 23
Slide Title: How Digest Authentication Works Keywords: Key Message: Slide Builds: 0 Slide Script: If the client is authenticated, IIS sends the requested document or data to the client. Slide Transition: So with a basic understanding of digest authentication, let’s talk a little about its cousin, Advanced digest authentication. Slide Comment: Additional Information: Active Directory 資料庫 Web 瀏覽器 23

摘要式驗證使用雜湊演算法傳送密碼的雜湊碼必要條件支援平台 IIS Sub-Auth (iissuba - LocalSystem)
Active Directory 密碼使用可逆式加密儲存在 AD 資料庫上支援平台 Windows 2000 Windows 2003

進階式摘要式驗證什麼是進階式摘要式驗證 ? 使用 MD5 雜湊必要條件 RFC 2617
IIS 6.0 (全新安裝，非升級 !) 2003 Active Directory Forest IIS Sub-Authentication 建立使用者帳號時事先編譯好雜湊碼 RFC 2617 UseDigestSSP Metabase 屬性 1: 使用進階式摘要式驗證 0: 使用摘要式驗證

憑證驗證在用戶端安裝有憑證，需要 SSL 憑證在伺服端可以對應到使用者帳戶 Request: Welcome.aspx
A certificate is a digital "key" installed on a computer. When the computer tries to access a server, the key will be automatically presented to authenticate the user. Client certificates can be mapped to Windows accounts in either a Domain or Active Directory. If you use the Windows Authentication Provider in ASP.NET, the application thread will run as the user to which the certificate is mapped. You may also implement custom authentication in ASP.NET where, for example, you could use the address (or a similarly unique field) contained within the certificate. From the client's perspective, security is seamless because the client is not required to log on using a logon page. This makes certificates an attractive option for automated business processes. Request: Welcome.aspx Response: Certificate request Request: Login.aspx + Certificate Response: Welcome.aspx Web Server Client Certificate Validation Domain Controller

Kerberos 使用 Kerberos ticket
IIS 7.0 驗證比較表驗證方式安全等級密碼傳送可跨越 Proxy 和防火牆用戶端需求匿名無是任何瀏覽器基本低 Base64 編碼是，但是危險大部份的瀏覽器摘要中雜湊 Internet Explorer 5 之後進階摘要 Windows 整合驗證高 NTLM 使用雜湊 Kerberos 使用 Kerberos ticket 否除非使用 PPTP VPN 連線 Internet Explorer 2 之後支援 NTLM; Windows Internet Explorer 5 之後支援 Kerberos 憑證是使用 SSL 連線 Internet Explorer、Netscape .NET Passport 加密

IIS 與 ASP.NET 身份驗證流程 IIS Web 瀏覽器允許該 IP address 和 domain? 拒絕存取否是
使用者身份驗證通過 ? IIS maintains security-related configuration settings in the IIS metabase. However, ASP.NET maintains security (and other) configuration settings in XML configuration files. While this generally simplifies the deployment of your application from a security standpoint, the security model adopted by your application will necessitate the correct configuration of both the IIS metabase and your ASP.NET application via its configuration file (Web.config). 否是執行 ASP.NET 程式有設定 ASP.NET impersonation ? ASP.NET 使用應用程式集區帳號沒有有 ACL 檢查通過 ? 使用指定帳號否允許存取是

ASP.NET Authentication Providers
ASP.NET 2.0 支援 4 種驗證 Provider Windows – 由 IIS 與 AD 處理驗證 Forms – 使用表單與 Cookies Passport – 使用 Passport 服務自訂在 Web.config 中設定 ASP.NET implements authentication using authentication providers, which are code modules that verify credentials and implement other security functionality such as cookie generation. ASP.NET supports the following three authentication providers: Forms Authentication. Using this provider causes unauthenticated requests to be redirected to a specified HTML form using client side redirection. The user can then supply logon credentials, and post the form back to the server. If the application authenticates the request (using application-specific logic), ASP.NET issues a cookie that contains the credentials or a key for reacquiring the client identity. Subsequent requests are issued with the cookie in the request headers, which means that subsequent authentications are unnecessary. Passport Authentication. This is a centralized authentication service provided by Microsoft that offers a single logon facility and membership services for participating sites. ASP.NET, in conjunction with the Microsoft Passport software development kit (SDK), provides similar functionality as Forms Authentication to Passport users. Windows Authentication. This provider utilizes the authentication capabilities of IIS. After IIS completes its authentication, ASP.NET uses the authenticated identity's token to authorize access. To enable a specified authentication provider for an ASP.NET application, you must create an entry in the application's configuration file as follows: // web.config file <authentication mode = "[Windows/Forms/Passport/None]"> </authentication>  <authentication mode = "[Windows|Forms|Passport|None]"> </authentication>

CardSpace 的目標讓網際網路存取更安全讓系統與系統之間的連接更安全讓使用者可以安全的識別與使用網站… 不論是對內還對外.
An Internet that is secure and safe for all Allow “Web 2.0, ” to flourish Connected Systems Integrated internal systems – tons of money wasted Federated external systems – lots of business opportunity

.NET Passport ? Windows Live ID 疑慮 ?

什麼是 Windows CardSpace ? Security Token 服務提供者使用者經驗
以卡片的方式呈現出使用者的數位身份當使用選擇卡片時 … 從 Identity Provider 取得 token 在使用者確認之後，送交給 Relying Party 使用者 100% 控制整個流程 ! Identity selector for Windows Part of .NET 3.0; uses WCF for WS-* stack User’s digital identities are a set of cards Each represents a relationship with an identity provider Contain metadata not data Displayed in a special, security-hardened UI When the user selects a card… CardSpace obtains security token from Identity Provider Gives it to the Relying Party with the user’s consent User has consistent experience and is in control Note CardSpace gets token from IP and gives it to RP – CardSpace does not have to actually open and parse the token. The token is opaque as far as CardSpace is concerned. CardSpace is thus security token agnostic: it can be in any format whatsoever. However, the IP should provide a plain text version of the token – the display token – so that CardSpace can show this to the user and get the user‘s consent to give the token to the RP. No password required. Remember: it’s all about getting a security token containing the claims from the IP to the RP under the user’s control. Security Token Service 使用者經驗服務提供者

架構在 WS-* Web Service 通訊協定之上
Windows CardSpace 容易且安全的管理使用者自己的身份識別資料使用在網站與 web services 的身份驗證上 And Windows CardSpace is an identity selector for Windows. You could probably use any number of ways for representing your digital identities but how do we give our identity in the real world? At a store I give my credit card, at a nightclub I show my driving license, at work I show my smartcard, in business I show my business card. In short, we use cards to represent our identities in the real world so it’s a natural metaphor for the user to adopt when choosing a digital identity to provide. CardSpace provides a familiar set of cards similar to if you opened your wallet or purse. When you want to identify yourself you just pick a card – no usernames and passwords! It’s consistent and secure. It has support for multi-factor authn like smartcards and kerberos and because CardSpace keeps track of where you have used your cards, it will alert you when a previously unvisited site – such as a phishing site pretending to be your normal online banking site - wants your credentials. 簡單安全不再需要 usernames 與 passwords 一致的登入與註冊方式防止釣魚多重驗證架構在 WS-* Web Service 通訊協定之上

demo 管理 Windows CardSpace

真實世界的 STS RP token token STS STS token token

CardSpace 運作流程使用者 Client
7 使用者決定可以送出 token Client 1 使用者要存取某項資源 4 使用者選擇 IP Note everything is abstract here – we have said nothing about how we implement this using technology – and that’s the whole point 5) Note that when the user requests a security token they have to authenticate themselves to their identity provider in some way. The IP does not give a token to just anyone who asks (suppose it’s your bank and you ask for info) – you have to have the right to ask for the token. This step of providing credentials while getting a token to identify yourself to the RP confuses some people so make sure you explain it carefully and it is understood. We are at an abstract level here but remember the four methods of authn in CardSpace v1 are X.509, Kerberos, username and password, self-issued token. Any method that can plug in as a X.509 Crypto Service Provider will work. Other methods will be added post-v1. 8) Token is released to RP; RP reads claims and allows access Important: the token format can be absolutely any format. As long as the RP asks for it and the IP can supply it we’re OK – that’s the point of the abstraction. The client does not have to understand the token format and cannot if the IP has encrypted the token so that only the RP can decrypt it. This revelation causes people to ask “how does the user know what’s in the token?” so they can approve its release. There is an optional “display token” which the IP provides to the client (encrypted for the client) which the client can understand. Those paying attention will then ask how do you know the display token == the token: We make the identity provider sign the claims with their key. Therefore, they can't later repudiate the claims and say "We didn't say that." If the machine-readable claims and the human-readable claims don't match, they can be held accountable via human/reputation/legal processes. However, in general, it's impossible for us to check that the machine-readable claims match the human-readable, because the claims can use any encoding whatsoever, and be signed using keys we can't decrypt. It's those very properties that let the Metasystem transmit claims from any individual system used by any identity provider. So the "problem" is completely unsolvable via technical measures, which is OK, because it's completely solvable at a human/reputation/legal level, which is where a lot of the real-world solutions to breach of trust are going to have to reside anyway. There is no way to keep the IP and RP from colluding if they are intent to do so, other than by making what is sent auditable. That is why we bind the display token to the computational token cryptographically. We have discussed this with important privacy and policy thinkers and explained our handling of the situation. Everyone has agreed and supported our approach. We need to get people to understand what it means to have an auditable system with digital signatures. And we need to get people to understand that technology must be combined with policy to solve these problems. How do you put a checksum on a karma rating without involvement of policy and auditing (meaning people define clearly what they are doing and it can be verified that that is what they have done?) Anyway, this is all implementation detail. This slide should keep things general without diving into too much detail. 5 3 檢查那些 IPs 可以滿足要求 ? 向該 IP 要求 token 2 RP 提出身份識別要求 6 根據 RP 要需求傳回 token 8 Token 送交給 RP Identity Provider (IP) Security Token Service (STS) Relying Party (RP)

選擇卡片 – 安全性使用者自行決定是否要信任使用X.509 憑證進行識別
Relying Party Identity Provider 使用X.509 憑證進行識別進一步進行對象確認使用 Logos Windows CardSpace 會負責追蹤卡片用到那裡去了 ! If a website is using an EV cert the IE7 address bar will be green. The CardSpace Trust dialog varies according to whether it is an EV cert and the cert has logos bound to it It appears for web services, web sites and identity providers: it appears for all parties that interact with the user. If a party doesn’t have a certificate then CardSpace will not interact with it. RP: trust dialog appears on first visit and following user cancellation IP: appears when user imports IP’s card How does this mitigate phishing? Well, if you get an pretending to come from your bank and you click on the link You won’t be prompted for an information card so you’ll know it’s not your bank You will be prompted for a card but first you’ll get the Trust dialog saying 1) it’s the first time you’ve been to the site and 2) it almost certainly won’t be an EV cert so you’ll get that warning too. You have to be really stupid to still provide your identity and even then the key you provide is pairwise hashed with the site you’re interacting with.

demo 使用 Windows CardSpace 登入網站

Federation by STS Contoso Fabrikam AD/STS Linux STS Fabrikam App
Emphasize that the Fabrikam token could be anything – some custom internal only token, it doesn’t matter. It also doesn’t matter that Fabrikam and Contoso run their applications on completely different technology stacks. The Fabrikam STS expresses the types of tokens (claims, issuer, type) it accepts in its policy and it is this that the CardSpace UI picks up on, highlighting only those cards that can meet the policy and graying out the others (only Lisa’s Fabrikam corporate card is highlighted, perhaps because an employeeid claim is required.) Fabrikam trusts Contoso to manage its users. It validates the SAML token from Contoso, checking the signature and it knows where it came from and that it is a trusted source. As the STS is a corporate one the obvious creds to use are the Windows logon creds (Kerb) App could be MS employees having a discount at Dell or any other service or site. “請給我一個 Fabrikam token !” SAML “請給我一個 token !” Contoso\Lisa “請出示您的身份 !” Fabrikam App “請出示您的身份 !” SAML Fabrikam “能不能幫我 …” Fabrikam “先從 Fabrikam STS 拿到 token 再說 !” “Lisa 您好，有什麼可以為您服務的嗎 ?”

網站應用網站客戶資料庫前端 Web 網站 Relying Party STS Identity Provider
HTTP/GET (保護頁面)   轉向到登入頁面 1 網站客戶資料庫 6 HTTP/GET (登入頁面)  2 登入頁面 (HTML) + x-informationcard 標籤使用者選擇卡片 3 5 HTTP/GET|POST 目標頁面 + token 前端 Web 網站透過 WS-Mex 與 WS-Trust 取得 token 4 Relying Party STS Identity Provider

網站應用 – 減少對網站的影響網站前端 Web 網站客戶資料庫 STS STS Identity Provider
HTTP/GET (保護的頁面)   轉向到登入頁面 1 網站傳出登入頁面 HTML HTTP/GET (登入頁面)  2 使用者選擇卡片 4 HTTP/GET|POST 目標頁面 + token 8 All we’re doing here is offloading the token processing from the front end web servers to separate servers that do the token processing and transformation to the token format accepted by the front end website (typically a cookie but not necessarily – in the future it could be a SAML token). Token cookie format is up to front end and STS to decide In the future, it is likely that front ends will consume tokens (such as SAML) directly 3 WS-Mex 前端 Web 網站透過 WS-Trust/RST 傳送 token 透過 WS-Trust/RSTR 取得 token 6 5 透過 WS-Mex 與 WS-Trust 取得 token 客戶資料庫 7 STS STS Identity Provider Relying Party

Login Page <button onclick="javascript:return infocardlogin.submit();"> Sign in with your Information Card </button> <form name="infocardlogin" target="_self" method="post"> <object type="application/x-informationcard" name="xmlToken"> <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion" > <param name="issuer" value=" > <param name="requiredClaims" value=" > </object> </form> public partial class Login_aspx : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) string xmlToken = Request["xmlToken"]; Token token = new TokenProcessor.Token(xmlToken); // Lookup the account using the uniqueId string username = MembershipHelper.GetUser(token.UniqueID); if (username != null) MembershipUser user = Membership.GetUser(username); // give the cookie back to the browser FormsAuthentication.SetLoginCookie(user.UserName, false); } Can also use a Binary Behavior… <html XMLNS:ic> <body> <form method="post" action=" > <ic:informationCard name='xmlToken‘ style='behavior:url(#default#informationCard)' issuer=' tokenType='urn:oasis:names:tc:SAML:1.0:assertion'> <ic:add claimType=' optional='false'/> <ic:add claimType=' optional='false'/> <ic:/informationCard> <input type="submit" name="InfoCardSignin" value="Log in using Information Card" id="InfoCardSignin" /> </form> </body> </html>

結論 CardSpace 是全新的身份驗證機制使用者身份資料由使用者自行管理滿足各類型應用程式身份驗證的需求

在何處取得 TechNet 相關資訊？訂閱 TechNet 資訊技術人快訊訂閱 TechNet Plus 參加 TechNet 的活動下載 TechNet 研討會簡報與錄影檔

<SLIDETITLE INCLUDE=0>Tag line</SLIDETITLE>
<KEYWORDS></KEYWORDS> <KEYMESSAGE></KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT></SLIDESCRIPT> <SLIDETRANSITION> </SLIDETRANSITION> <COMMENT></COMMENT> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>

新一代身份驗證機制 - Windows Card Space

Similar presentations

Presentation on theme: "新一代身份驗證機制 - Windows Card Space"— Presentation transcript:

Similar presentations

About project

反馈

请登录

Auth with social network:

新一代身份驗證機制 - Windows Card Space

Similar presentations

Presentation on theme: "新一代身份驗證機制 - Windows Card Space"— Presentation transcript:

Similar presentations

About project

反馈