Category: SAML

Azure AD Seamless SSO

 

 

 

 

Seamless SSO，一個曾經覺得好難好難嘅東東。但係經過呢兩三年前Configure Kerberos，同開始接觸SAML後得到嘅經驗。 Seamless SSO唔再係咁難以觸摸。

第一，都係要多謝我哋偉大嘅Microsoft。Azure AD係上年九月左右嘅Update。 Pass-Through Authentication。Microsoft 解釋Benefit係Authentication會返返OnPremises AD做，可以唔需要開Password Sync。

係另一方面，雖然已經有ADFS WAP，但係係DMZ嘅關係，係無join AD。所以Azure Pre-Authentication係用唔到。係另一方面，雖然已經有ADFS WAP，但係係DMZ嘅關係，係無join AD。所以Azure Pre-Authentication係用唔到。但係用Application Proxy Connector就無呢個限制。Application Proxy Connector可以安裝係任何一部Domain Joined Server。係呢個因素之下，Machine Account 行 Kerberos就絕對無難度。

步驟可以照跟Microsoft。謂獨有一個Step令我特別留意，因為同以往Configure KCD唔同。Common係Delegation – “Trust this computer for delegation to specified services only” 下面嘅Section係揀 “Kerberos only”，但係今次Config Application Proxy Delegation係用”Use Any Authentication Protocol”

  • Reconfirm that the connector host has been granted the rights to delegate to the designated target account’s SPN, and that Use any authentication protocol is selected. For more information about this topic, see SSO configuration article

https://docs.microsoft.com/en-us/azure/active-directory/application-proxy-back-end-kerberos-constrained-delegation-how-to

以下兩條Youtube都介紹得嘅清楚，值得一睇

Reference

https://www.youtube.com/watch?v=PyeAC85Gm7w

https://www.youtube.com/watch?v=vt2R4P4xLQA

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-application-proxy-sso-using-kcd

Work Place by Facebook integrate with Azure AD – Part III

 

 

 

 

Part III

做完對上兩邊Config，係時間測試下成果。

首先係去 “https://mydomain.facebook.com”
WorkPlace login page 顯示 “Your company has enabled single sign-on.”
變成冇得係到用”UserName/Password” Auth

“User Name / Password”  vs “SSO”

 

 

 

 

 

 

 

 

 

 

 

當噉”Log In” 就會Redirect 去Azure嘅Login Page （第一步成功）

 

 

 

 

 

之後就變成同Office365 Login 一樣，需要用 AD Credentail / Client Certificate 做 Auth

係已經Join Domain嘅PC。因為有Kerberos Auth，當Page redirect去到Azure Login,只需要打Username (UPN)，往後嘅login process就會用Kerberos 完成

Work Place by Facebook integrate with Azure AD – Part II – Azure AD Enterprise App Configuration / Work Place SSO Authentication

 

 

 

 

Part II

續Part I。Work Place Subdomain 準備就絮～開始戲肉。SAML Config。 如SalesForce一樣，大路嘅Idp（ADFS / Azure AD /G Suite / OKTA / One Login / Ping Identity)都有article講點做。基於Domain 已經係 Azure AD 上面Federated，亦即係同Office365 一樣， 會返ADFS Server 做Auth / MFA。 所以係唔需要考慮ADFS 個article 點做。

SAML configuration 唔難。基本都係兩邊資料 Copy n Paste。 但係最鑊，最怕就係兩邊各自各描述。Field名唔知邊個對邊個。

今次都係，先Configure 係Azure AD，First Try照跟Article係唔夠Parameters

大路照跟可以，但係留意以下Step3 >>>>>> 跟Azure咁做係誤以為夠。第一唔清楚咩係Identifier。跟Azure Article 咁做係唔夠，Sequence亦唔啱。 第一唔清楚咩係Identifier。。。。亦要Tick “Show advanced URL settings”嘅CheckBox

係要返WorkPlace， Dashboard，Authentication，係SAML Authentication 呢個Page 下面嘅Info

Azure “Identifier” = WorkPlace “Audience URL”                                             >>> “https://www.facebook.com/company/15digitvalue”

Azure “Reply URL” = WorkPlace “ACS (Assertion Consumer Service) URL” >>> “https://domain.facebook.com/work/saml.php”

Confusing Sample from Azure

3. On the Workplace by Facebook Domain and URLs section, perform the following steps:

Configure Single Sign-On

a. In the Sign-on URL textbox, type a URL using the following pattern: https://<instancename>.facebook.com

b. In the Identifier textbox, type a URL using the following pattern: https://www.facebook.com/company/<instancename>

係Azure做完上半，噉Save。 再Scroll Down落下面噉”Configure Workplace by Facebook”。 接落嚟嘅Information要放返落WorkPlace嘅Authentication Page。
WorkPlace呢邊係兩個URL相對容易啲啲，不係啲名都係唔match

Azure “Azure AD Single Sign-On Service URL” >>> WorkPlace “SAML URL”

Azure “Azure AD SAML Entity ID” >>> WorkPlace “SAML Issuer URI”

最後當然係Paste 返係Azure Download 嘅Signing Cert落去。 先去噉”Test SSO”。先會Pass 個Test Auth。

Cont’d @ Part III

Reference Link

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-facebook-at-work-tutorial

https://developers.facebook.com/docs/workplace/authentication/sso

Work Place by Facebook integrate with Azure AD – Part I – Subscription + Upgrade to Premium Work Place Premium

 

 

 

 

 

絕對唔係新野。 一兩年前記得叫Facbook for Work，但係搵唔到方法申請。機緣下 上星期睇到Azure 嘅article。

WorkPlace by FB要開Account唔難，去https://facebook.com/work 用Corporate Email account就開到。但就咁普通係做唔到任何Customization嘅（包括Authentication Integration)…….. e.g. “https://work-xxxxxxxx.facebook.com”

所以。。 第一件事係upgrade去Work Place Premium。 Procedure都係基本verify domain ownership。 一係Domain RootLevel 嘅Web Server Webpage放token，另一選擇就係DNS 落 TXT Record (後者絕對易做得多，但係估唔到FB Support話睇唔到我隻Domain host 係邊，唔講 TXT Record 個做法我知……玩野)

時間關係。。 兩日等左 DNS Record Creation 同往後FB嘅vertificaton，之後再需要等FB Subdoamin 由https://work-xxxxxxxx.facebook.com 變成我哋嘅 “https://mymdomain.facebook.com”

當Domain完全轉好（係會慢慢逐小逐小變出嚟，所以收左FB Email話Verification OK，最後都等左兩個鐘（封Mail講十分鐘OK….呃人）

Cont’d – Part II

Reference Link

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-facebook-at-work-tutorial

https://developers.facebook.com/docs/workplace/authentication/sso

初試SAML大集會 ….. 1.OKTA 2.Sales Force 3.ADFS

saml  salesforceoktaadfs-logo

絕對係新挑戰 !!!!!

SAML      一直係以往唔多敢去掂嘅野。相比Kerberos，SAML有自己覺得好難睇嘅XML (Recursive xml）。諗起都怕怕。怕怕。

基如嚟緊好高機會要用同自己嘅未雨綢繆，決定放手睇睇佢……

第一係搵用嘅IdP（Identity Provider) 同SP(Service Provider)
雖然已經有ADFS係到可用， 但係ADFS唔係呢個今次Buildup最初會用嘅。

SalesForce已知嘅係大路嘅Service Provider。。 Production 要錢無可能。但係Developer Edition係兩個User免費 ，未搵到有無Support。 超孤寒。。。。
已IdP係搵嘅當中睇到OKTA。。 佢對比好啲。 三個App，一百個User係永久免費，亦有Support。 好啲

好。。。 準備完成。。 開工

大至上嘅Concept

rtaimage

AD 係Identity  Source， 最初令自己亂嘅係點開OKTA嘅UserID.
因為係未安OKTA Agent同AD link埋之前。 OKTA 自己嘅user account都係用同一個domain suffix. Password 一樣會難去確定。
但係發現當安完OKTA Agent match 好user之後。 係得返AD password. 即係唔需要搵account 做local account。

之後係Salesforce拖OKTA。
兩者integration當個中有個伏位係OKTA。 Support SAML 嘅 App 當中，Salesforce App有三個。而”Salesfforce.com(Federate ID)”係有問題，唔work。。。 因此咁而報case support。。

開始時候做法幾乎一樣，都係要諗用另一個account作為Full Rights Admin。亦因為呢個原因。係Salesforce create自己嘅account用唔同Password。
係OKTA加Salesforce app, 同Salesforce 裡面config Single Sign-On幾乎係照跟就可以。所以假若唔係 “Salesforce(Federate ID)”出事。。
係可以兩日整好。。。

Set好後不論係 SP Initiated（Salesforce 會有多個Auth Option)還是IdP Initiated（OKTA App list,SSO 直接list）都會 開到。。

最後，係Salesforce 駁ADFS。

步驟唔多，仍然要係Salesforce portal加Single Sign-On setting
但係伏位係ADFS Server入面嘅Issuer
當開 FederationMetadata 睇嘅時候
“https://adfsserver.domain.com/federationMetadata/2007-06/FederationMetadata.xml”

adfssalesforceconfig

ADFS 入面嘅Metadata.xml , 佢嘅Element名叫”entityID”, 而個名同ADFS server Web URL睇落一樣，但係佢唔係https,係http 。
呢一樣錯，就會fail。
SAML Assertion會check 到mismatch。。。。

Done ! That’s it

Reference:

Salesforce integration with OKTA

http://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-in-Salesforce.html

Salesforce integrate with ADFS 3.0

https://developer.salesforce.com/page/Single_Sign-On_with_Force.com_and_Microsoft_Active_Directory_Federation_Services

Troubleshooting Tools

https://www.samltool.com/base64.php

SharePoint 2013 – SAML Auth

index

 

 

 

對比Kerberos, SAML絕對係未明但係照跟照做嘅。 係本身行緊嘅SharePoint2013 幾乎無變動，只需要Extend 其中一個 Web Application作為Target.  其餘只係跟Sample Syntax照改。 Sample 有 minor typo mistake但係唔會死人

Reference

http://summit7systems.com/beginners-guide-to-claims-based-authentication-ad-fs-3-0-and-sharepoint-2013-part-iii-configuring-sharepoint-2013-for-ad-fs/

https://technet.microsoft.com/en-us/library/hh305235.aspx