有关什么在Android、Java等非微软平台上创立高信任的SharePoint应用程序

至于如何在非微软平台上建立高信任的SharePoint应用程序

原文
http://blogs.msdn.com/b/kaevans/archive/2014/07/14/high-trust-sharepoint-apps-on-non-microsoft-platforms.aspx

1.前言

 

开赛明之,哥无代码发表,也不提供解决方案。
作者只是表达在非微软技术平台上确立低信任或是高信任应用程序是拾分自由的(PS:也是丰裕痛苦的)。
作为一个微软技能的研发者,我也长日子没有写Java或是PHP代码了,文中吾力所不及给每种平台建立示例代码,抛砖以引玉吧。

当你去建立1个SharePoint 二零一三应用程序时,Visual Studio
二〇一二,会让您采纳:

1、使用Azure
ACS

2、使用三个证书

 

图片 1

本条选项就意味着在问,目标 SharePoint
服务器场怎样定义信任设置,并把有关设置保存在Web.config文件中。要么你利用低信任ACS设置“client
ID”和”client secret”或是使用高信任来设置”client ID”
、”证书路径”和“证书密码”。

2.理解OAuth和信任

由此这几个PodCast, Office 365 Developer Podcast: Episode 002 with Radi
Atanassov
,
Radi 详述了SharePoint 使用OAuth ,并且把它形象地称为 “三角验证”
,当把利用设置成使用Azure
ACS的时候,应用需求去与ACS通讯,提供一个“Refresh
Token”,并且拿到三个Access Token, “Refresh Token”
是应用程序从SharePoint 的服务器取得的,但以此”Refresh Token” 也是Azure
ACS 之前发给SharePoint的。在这么些形式下, 应用程序和SharePoint服务器,
不直接相信对方,而是经过Azure ACS 建立两两亲信关系,
所以我们叫那“低信任”.  如若要更进一步精通那种“OAuth舞步”, 去这一个URubiconL
看我们的二零一三 session, Understanding Authentication and Permissions with
Apps for SharePoint and
Office

图片 2

低信任模型既可以被Office 365运用也足以被单独的SharePoint
2011服务器使用。

可严酷的有血有肉,总是发生!很多客户根本没有办法去设置集团内部的SharePoint
2012与Azure ACS通讯,因为Azure ACS是微软的服务器,(公司中间的SharePoint
二〇一二不允许连接外网,固然SharePoint
2011方可连外网有个别国家也有防火墙不容许访问海外一些网站)。很好!产品团队于是可以不接纳Azure
ACS,作为专业人员的我们也要明了,对于OAuth 2.0来说,Azure
ACS已毕了S2S协议那但是微软王国标准的OAuth
2.0作法,这是有范冰冰女士(Fan Bingbing)的。在“高信任”的证实方案里,
因为我们着想到SharePoint 服务器与APP
是3个特别铁的弟兄,不需求第壹方去有限支撑什么。APP
使用X.509证书去给“TOKEN”签名,然后SharePoint 再对这么些签字举行信任。

“高信任”,并不意味“高授权”,不是说APP可以一向去删除或是干掉服务器里的事物,“授权”照旧通过动用APP的此人来控制的。
只不过APP可以决定OAuth2 access
token
创设的经过,不需求微软的ACS服务器来消除。SharePoint
场的管理员使用公钥注册3个“深信不疑的安全TOKEN颁发者
SPTrustedSecurityTokenIssuer, 然后App 使用那么些注明的私钥
签名,正因为私钥的特色,所以 SharePoint 会信任那几个APP。
图片 3

可爱的是单身的服务器可以挑选2者,而Office
365的APP是没有办法使用“高信任” 形式的,
因为作为三个微软开发者的你,黑不到OFFICE 365的服务器里去创立证书!.

何况了:人家微软的Office
365不依赖微软的ACS服务,难道信任你的APP不成。

3.低信任APP与非微软平台

 如若您付出基于Office
365的程序上,哥劝你就平昔采纳“低信任APP”,那也不难,对于APP开发者的你也不管签名发证书的工作,在网页上申请Client
ID和 Client
Secret后,在您的代码里就是写多少个程序保存一Token之类,就行了。网上那种小说,见惯不惊,例如:1.
Todd Baginski 对于Node.js 上付出SharePoint
作了那些美丽的发言。也发布了演示PHP操纵SharePoint 2012 SharePoint 2013:
Perform operations on SharePoint Document Library from PHP
site
. 在这么些模型里,要用到
JWT library 库去解析 由 SharePoint 发给你的context token ,进程就是获取
ACS U本田CR-VL, 把Refresh token 提交去赢得access token.

2.
等同,对于你自主的SharePoint网站创立1个低信任APP也是很有只怕的,上边的篇章真是大拿之作:怎样利用Office
365去印证一个自主SharePoint 网站的提供商承APP。

How to: Use an Office 365 SharePoint site to authorize provider-hosted
apps on an on-premises SharePoint
site

在那个模型里,你创立多个Office365的tenant,然后成立1个亲信从你的服务器到Office
365的服务器,你不必要对此Office 365做其余配置,你只是急需它去读取Azure
ACS给您准备的命名空间。一但配备好,无论它是还是不是微软平台,你就足以采纳Client
ID和Client Secret.
在自主的SharePoint服务场配置达成后,你不要求操心管理X.509证书或是证书颁发者的题材,你也不须要担心开发人员有X.509密码,大概滋生的哈密难题,看了那篇小说,你就有点困惑我们为啥非要搞出多个“高信任”形式呢?? 

图片 4
 

  1.   创立二个ACS代理(在你的独立SharePoint 服务器场)

  2.  安装你的SharePoint的签字证书到您Office 365的tenancy.

  3.  把合格的域名加入到你SharePoint
    二〇一三场(那个场你想去运营APP),在您的Office 365
    tenancy服务的princels名称.

  4.  在你的服务器场,创立五个APP管理代理。

您可以瞥见你的APP和其中拥有的多寡都存在你本身的SharePoint服务器上,你只是利用Azure
ACS用来开展APP注册和表达,从开发者的角度来看,你只是简不难单地采用了2个client ID 和client secret, 而让你可以无压力或是根本不要求自义就采用 JWT
libraries .  那就是干什么自身想:“低信任”
对于“高信任”来说,减弱管理的繁杂真是无比的优势。4.布署高信任APP

任由你用哪些的技艺建立APP,Visual Studio 、ASP.NET MVC running on IIS
或是 Azure Web Sites,或是使用Eclipse 或是 汤姆cat (Apache and Linux),
这几个注册的步调,是一点一滴等同的,如下的指令必须由管理员在控制台的界面中完毕,首要的目的就是成功X.509证书的相信配置:

PowerShell for High Trust Apps

  1. #Tell SharePoint
    to trust the certificate
  2. $publicCertPath = “C:\HighTrust.cer”
  3. $certificate = Get-PfxCertificate $publicCertPath
  4. New-SPTrustedRootAuthority -Name “HighTrust” -Certificate $certificate
  5.  
  6. #Get the tenant
    ID.  For on-premises default installations,
  7. #this will be
    the same as the SharePoint farm ID
  8. $spweb = Get-SPWeb “https://mysite.contoso.com
  9. $realm = Get-SPAuthenticationRealm -ServiceContext $spweb.Site
  10.  
  11. #Specify the
    issuer ID
  12. $issuerID = “b77a601b-3133-4567-bb37-f147f61dd332”
  13. $fullIssuerIdentifier = $issuerId + ‘@’ + $realm
  14.  
  15. #Create a
    trusted security token issuer based on the certificate
  16. New-SPTrustedSecurityTokenIssuer -Name “Contoso S2S HighTrust
    Apps” -Certificate $certificate -RegisteredIssuerName $fullIssuerIdentifier IsTrustBroker
  17.  
  18. #IISRESET is
    needed, otherwise settings won’t be applied for 24 hours
  19. iisreset

 

完全的安排步骤,可以参照如下的篇章:

 “How to: Create high-trust apps for SharePoint 2013 (advanced
topic)
”. 这一个APP将会动用证书,证书密码和文告的ID去得到二个ACCESS
TOKEN, Visual Studio提供了如此的工具去完结这些。

图片 5

 

可悲呀!
非微软的先后,必需要去管理这一个值,以去获取Access Token。

4. JWT Tokens

SharePoint 使用JWT tokens 来进行OAuth认证。可别让这些英文“token”
吓坏你那几个好基友了,你就把这几个东东当成十二分丰硕丰硕(此处省略127字)
复杂的加密形式.  JWT tokens 是 JSON 对象, 那意味着它就是name-value
pairs那种样式,感兴趣你可以读读 The JWT specification
draft

给SharePoint 的 access token 再介绍一遍好了!再说一回! 她不怕JWT
token, 

怎样你还想驾驭它, 可以读读那些啊! “Creating a Fiddler Extension for
SharePoint 2013 App
Tokens
”. 

图片 6

上边可以看看其领会就是一对对键-值,它有12钟头的有效期,取得后你就可以“作威作福”哦。。。。。。具体内容
如下表所示:

aud Audience.  The value is 00000003-0000-0ff1-ce00-00000000/<hostname>@<realm*>  .    The hostname is the FQDN of the web application root or the host-header site collection root.  The realm is the GUID that represents the SharePoint tenant.
iss Issuer. <IssuerID>@<realm*>. The issuer ID is obtained when you register the SPTrustedIdentityTokenIssuer. The realm is the GUID that represents the SharePoint tenant.
nbf Not before. The Unix epoch time upon which the token started being valid.
exp Expires. The Unix epoch time upon which the token expires.
nameid The identifier for the user (more info below)
nii The identity provider used to rehydrate the user.  One of the values:
urn:office:idp:activedirectory
urn:office:idp:forms:membershipprovidername
trusted:samlprovidername (as noted in Steve Peschka’s example below, this is what is actually configured as opposed to the documentation)
actortoken The token for the application.

\ 现实又是可爱的,当您安装了SharePoint 二零一二, 只有三个tenant ID,
realm与SharePoint farm ID又同样,可以经过PowerShell的下令:*

Get -SPFarm | select ID 得到。

上边我们再解决:actortoken.  那与outer token相反,actortoken
标识的是APP.

aud Audience.  The value is 00000003-0000-0ff1-ce00-00000000/<hostname>@<realm*>  .    The hostname is the FQDN of the web application root or the host-header site collection root.  The realm is the GUID that represents the SharePoint tenant.
iss Issuer.  <IssuerID>@<realm*>.  The issuer ID is obtained when you register the SPTrustedIdentityTokenIssuer.  The realm is the GUID that represents the SharePoint tenant.
nbf Not before.  The Unix epoch time upon which the token started being valid.
exp Expires. The Unix epoch time upon which the token expires.
nameid Identifier for the app.  <Client ID>@<realm>.  The client ID uniquely identifies your app, this is provided by using AppRegNew.aspx or provided when registering an app in the Office Marketplace.

Inner token, outer token…太奇怪了,哥就不翻译了,避防又错了, 看例子!
我们本身一旦使用这一个值,那样不难了然一些,同样大家上例中的示例值,也是一律的:

SharePoint site mysite.contoso.com
SharePoint realm ID 6305dc22-8cb8-4da3-8e76-8d0bbc0499a5
SPTrustedSecurityTokenIssuer issuer ID b77a601b-3133-4567-bb37-f147f61dd332
Client ID 06d847ca-011f-4965-ac1f-5ad14740ad89

末段, 解码TOKEN的代码大家应用了上例的示例值:

Sample Access Token Body

  1. {
  2.     aud:    00000003-0000-0ff1-ce00-000000000000/mysite.contoso.com@6305dc22-8cb8-4da3-8e76-8d0bbc0499a5,
  3.     iss:    b77a601b-3133-4567-bb37-f147f61dd332@6305dc22-8cb8-4da3-8e76-8d0bbc0499a5,     
  4.     nameid:
    s-1-5-21-3304015898-3601453682-3711364722-500,
  5.     nii:    urn:office:idp:activedirectory,        
  6.     nbf:    1320176785,     
  7.     exp:    1320219985,             
  8.     actortoken:     
  9.     {         
  10.         aud:        00000003-0000-0ff1-ce00-000000000000/mysite.contoso.com@6305dc22-8cb8-4da3-8e76-8d0bbc0499a5,
  11.         iss:        b77a601b-3133-4567-bb37-f147f61dd332@6305dc22-8cb8-4da3-8e76-8d0bbc0499a5,         
  12.         nameid:     06d847ca-011f-4965-ac1f-5ad14740ad89@6305dc22-8cb8-4da3-8e76-8d0bbc0499a5,                        
  13.         nbf:        1320176785,         
  14.         exp:        1320219985,                          
  15.           trustedfordelegation:
    true
  16.     }
  17. }

看望您就会了然,拆开内容之中没有稍微变量。

ACS格局的 S2S 协议号称是规范的 OAuth 2.0 模型,你也足以参考学习下:
[MS-SPS2SAUTH]: OAuth 2.0 Authentication Protocol: SharePoint
Profile
.

5.”高信任”APP 与非微软平台

好吧,兄弟是笔者误导你了,你只要如此还在坚持不渝使用“高信任”APP,有些业务本人还得和您交待清楚。
如果你不在微软平台下开发那种APP,你会发觉找遍MSDN你都没有没有方法找到2个不行使TokenHelper.cs,的例证。而文件中的类,有巨长的代码,你根本不只怕把那个东东改建成非微软的一平台的代码。

TokenHelper.cs,真正的效应在于帮助您去解码和加密Jwt
TOKEN。

当您创建三个新的APP,假若您利用Visual Studio
,它会活动很不难地自动化地帮您填上富有有关的 OAuth 对象和值的怎么的。

其一类就是TokenHelper.cs,它即有方法可以让你通过Azure ACS 来使用“低信任”
apps,也有措施去落到实处“高信任”

Windows Identity

  1. public static string
    GetS2SAccessTokenWithWindowsIdentity(
  2.     Uri
    targetApplicationUri,
  3.     WindowsIdentity
    identity)
  4. {
  5.     string realm = string.IsNullOrEmpty(Realm) ?
    GetRealmFromTargetUrl(targetApplicationUri) :
    Realm;
  6.  
  7.     JsonWebTokenClaim[] claims = identity
    != null ?
    GetClaimsWithWindowsIdentity(identity) : null;
  8.  
  9.     return
    GetS2SAccessTokenWithClaims(targetApplicationUri.Authority, realm,
    claims);
  10. }

地点的法子接受3个WindowsIdentity,然后成立二个Access token。
因为那个措施是吸收WindowsIdentity的,它看起来不像能够被非微软技术平台所用,不过我们看看里面所用的这些形式:GetClaimsWithWindowsIdentity,
没有何样尤其之和呀!!!

Claims Identity

  1. private static JsonWebTokenClaim[]
    GetClaimsWithWindowsIdentity(WindowsIdentity
    identity)
  2. {
  3.     JsonWebTokenClaim[] claims = new JsonWebTokenClaim[]
  4.     {
  5.         new JsonWebTokenClaim(NameIdentifierClaimType,
    identity.User.Value.ToLower()),
  6.         new JsonWebTokenClaim(“nii”, “urn:office:idp:activedirectory”)
  7.     };
  8.     return
    claims;
  9. }

代码所做的,无非就是加了1个claim
,首个叫nameid,它的值是sid,第二个叫nil,
告诉SharePoint如何去把nameid值映射到2个identity
provider,在那些场合下,nil值就是“urn:office:idp:activedirectory”.  
参数“nameid” 和“nii” 对SharePoint是一定的, 你可以把那一个阐明(claim)加到
the JWT token.

6.值从哪来

TokenHelper.cs 是Visual
Studio生成的,假诺你采纳别的的平台,你就非得改造. 
值到何地去的标题大家上一节已经消除,以往我们就化解值从何地来的难题。

issuerid

当你创立注册SPTrustedSecurityTokenIssuer时,issuer ID就生成了,那是 GUID
全体小写.

Client ID

您通过 AppRegNew.aspx 注册APP时填的大概自动生成的。

realm

做客SharePoint 网站的如下url: “/_vti_bin/client.svc”
,在拜访的时候添加这么些的HTTP head: “Authorization: Bearer “. 
参考TokenHelper.cs中的格局:

Obtaining the Realm

  1. public static string
    GetRealmFromTargetUrl(Uri
    targetApplicationUri)
  2. {
  3.     WebRequest request = WebRequest.Create(targetApplicationUri +
    “/_vti_bin/client.svc”);
  4.     request.Headers.Add(“Authorization: Bearer
    “);
  5.  
  6.     try
  7.     {
  8.         using
    (request.GetResponse())
  9.         {
  10.         }
  11.     }
  12.     catch (WebException e)
  13.     {
  14.         if (e.Response == null)
  15.         {
  16.             return null;
  17.         }
  18.  
  19.         string bearerResponseHeader =
    e.Response.Headers[“WWW-Authenticate”];
  20.         if (string.IsNullOrEmpty(bearerResponseHeader))
  21.         {
  22.             return null;
  23.         }
  24.  
  25.         const string bearer = “Bearer realm=\””;
  26.         int bearerIndex =
    bearerResponseHeader.IndexOf(bearer, StringComparison.Ordinal);
  27.         if (bearerIndex
    < 0)
  28.         {
  29.             return null;
  30.         }
  31.  
  32.         int realmIndex =
    bearerIndex + bearer.Length;
  33.  
  34.         if
    (bearerResponseHeader.Length >= realmIndex +
    36)
  35.         {
  36.             string targetRealm =
    bearerResponseHeader.Substring(realmIndex, 36);
  37.  
  38.             Guid
    realmGuid;
  39.  
  40.             if (Guid.TryParse(targetRealm,
    out
    realmGuid))
  41.             {
  42.                 return
    targetRealm;
  43.             }
  44.         }
  45.     }
  46.     return null;
  47. }

上述代码很简短,转成你的阳台的代码就行了,对于O365以来,它设计就是给众积雨云用户使用的,realm对每多个云用户是不相同的。 

有点意思:
假如你在“低信任”APP那节,配置了您的服务器与O365服务器之间的深信的话,realm的值是浮动的哦。

nameid and niia

当配置“高信任” apps, MSDN 文档讲明Web Application 必须拔取 Windows
Authentication.  记住在你的APP和SharePoint之间唯一的安全的通讯就是JWT
token在表达的头“Bearer
”,那是通过SSl传送的。当在TokenHelper中的代码应用WindowsIdentity所做的绝无仅有事情就是取得SID,没有其他对象。所以,唯一的说辞APP的Web
Application要求选用Windows
验证措施,就是因为啥让TokenHelper.cs使用WindowsIdentity
对象拿到用户的SID. 
你可以更改TokenHelper.cs具体做法使用别的措施得到用户的SID.

前一节 “JWT Tokens” 介绍了nameid (outer token) 它的值是 SID, 从二个WindowsIdentity 对象得到. 
作为非微软技术大拿的小兄弟你什么样去做,得到使用者的SID 呢?

  1. 使用LDAP 这么些模型去从Active Directory拿到新闻. 

三个汉子用PHP化解他了,您可以看看: PHP – Get users SID from Active
Directory via
LDAP

  1. 万一这么些用户并不是AD中的如何是好? 我们可以应用 ADFS 或是 Ping 或是
    其余一些 SAML provider,  笔者特意喜欢那几个办法,你可以跟随小编的做法,那用到
    FBA 、SAML claims  Steve Peschka 有小说, Using SharePoint Apps with
    SAML and FBA Sites in SharePoint
    2013
    ,那是拔取SAML or FBA 用户来说,这几个方法怎么写。

Assert the user identity

  1. private static JsonWebTokenClaim[]
    GetClaimsWithClaimsIdentity(
  2.     System.Security.Principal.IPrincipal
    UserPrincipal,
  3.     IdentityClaimType
    SamlIdentityClaimType, TokenHelper.ClaimsUserIdClaim id,
  4.     ClaimProviderType
    IdentityClaimProviderType)
  5. {
  6.  
  7.     //if an identity claim
    was not found, then exit
  8.     if (string.IsNullOrEmpty(id.ClaimsIdClaimValue))
  9.         return null;
  10.  
  11.     Hashtable claimSet = new Hashtable();
  12.  
  13.     //you always need nii
    claim, so add that
  14.     claimSet.Add(“nii”, “temp”);
  15.  
  16.     //set up the nii claim
    and then add the smtp or sip claim separately
  17.     if
    (IdentityClaimProviderType ==
    ClaimProviderType.SAML)
  18.         claimSet[“nii”] = “trusted:” +
    TrustedProviderName.ToLower();  //was
    urn:office:idp:trusted:, but this does not seem to align with what
    SPIdentityClaimMapper uses
  19.     else
  20.         claimSet[“nii”] = “urn:office:idp:forms:” +
    MembershipProviderName.ToLower();
  21.  
  22.     //plug in UPN claim if
    we’re using that
  23.     if (id.ClaimsIdClaimType
    == CLAIMS_ID_TYPE_UPN)
  24.         claimSet.Add(“upn”,
    id.ClaimsIdClaimValue.ToLower());
  25.  
  26.     //now create the
    JsonWebTokenClaim array
  27.     List<JsonWebTokenClaim>
    claimList = new List<JsonWebTokenClaim>();
  28.  
  29.     foreach (string key in
    claimSet.Keys)
  30.     {
  31.         claimList.Add(new JsonWebTokenClaim(key,
    (string)claimSet[key]));
  32.     }
  33.  
  34.     return
    claimList.ToArray();
  35. }

 

上例中,它参与了 nameid 和nii 一个注脚, nameid 被映射到了 UPN, email,
或是SIP.  在小说中,它表明也这些特性的详尽效能. 怎么着你的SharePoint
服务器使用 FBA 或是 SAML 来声称用户, 那几个资源对你将极度有效!
最重大的是,那会加剧你对“高信任”方式APP中如何拔取用户配置文件服务的首要精晓。
User Profile ServiceApplication也很首要哦,兄弟你有趣味多多探究下边2篇吧!

SharePoint 2013 User Profile Sync for Claims
Users

OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That
and What do I Need to
Know

正因为大家的APP运营在各个不用的阳台上,甚至动用不用的认证架构全部很难有限匡助用户都以使用AD的,既然SharePoint可以使用不一致的用户那么您的次第也应当合作,不是嘛?

 

7. X.509证书

当您创设二个“高信任”APP,即便你利用Visual Studio
,你无法不提供三个路子去生成三个证件和证件密码,X.509 证书用于对Access
Token举办签字。这些签名就好像Oauth2的客户密码(client
secret)的意义一样,在很高档别Json对象体系化成三个字串,那个字串是base64
Url编码的,然后再使用签名。 同样的步骤,在大家运用ACS
验证措施时也暴发,不过此时用于签名的是client
secret,所以你应该可以找到一个库用来形成JWT
token然后还是可以拓展签约的操作(当然是X.509)。

Visual Stdio 程序会在开创APP时,自动地引用
Microsoft.IdentityModel.Extensions. 作者使用反编工具Telerik JustDecompile
反编了 Microsoft.IdentityModel.Extensions 作者利用Visual Studio 二〇一二制造使用证书的SharePoint APP 的档次,
移除Microsoft.IdentityModel.Extensions, 添加上本人要好的
Microsoft.IdentityModel.Extensions项目.  上面就 JWT token
创造和签字再拓展一些增添.

步骤就好像是如此:

  1. JWT token 有二个部分:头、正文.  头指示了它的类型 (JWT) 和算法,
    正文就好像我们前面说的 access token那样 之间用点分隔 “.”
  2. 头被编码成JSON, 编码格局:base64UrlEncoded.
  3. 本文被编码成JSON, 编码方式:base64UrlEncoded.
  4. 贰个base64UrlEncoded 值使用点连接 “.”
  5. 结果运用 X.509 证书,使用奥迪Q3SA SHA256 签名算法,和SHA256 数字算法.
  6. 上一步结果延续举行base64U福睿斯LEncoded编码
  7. 第 4 步结果排在第陆,步结果前, 用点连接 “.”

那有点代码,让您可以知道那么些进度:

Code Snippet

  1. IDictionary<string, string> headerClaims =
    jwt.CreateHeaderClaims();
  2. IDictionary<string, string> payloadClaims =
    jwt.CreatePayloadClaims();
  3.                         
  4. string encodedHeader = Base64UrlEncoder.Encode(headerClaims.EncodeToJson());
  5. string encodedBody = Base64UrlEncoder.Encode(payloadClaims.EncodeToJson());
  6.             
  7. string formattedClaims =
    string.Format(CultureInfo.InvariantCulture,
    “{0}.{1}”, encodedHeader,
    encodedBody);
  8. string encodedSignature =
    this.Sign(formattedClaims,
    jwt.SigningCredentials);
  9.  
  10. return string.Format(CultureInfo.InvariantCulture,
    “{0}.{1}.{2}”, encodedHeader,
    encodedBody,
    encodedSignature);

那边的“jwt.SigningCredentials” 是何许?  你看看
TokenHelper.cs,就精晓那就是  X.509 证书. 在您的平台上,
你须要贰个密码和私钥去变通结果。 

Code Snippet

  1. private static readonly string
    ClientSigningCertificatePath = WebConfigurationManager.AppSettings.Get(“ClientSigningCertificatePath”);
  2. private static readonly string
    ClientSigningCertificatePassword = WebConfigurationManager.AppSettings.Get(“ClientSigningCertificatePassword”);
  3. private static readonly X509Certificate2 ClientCertificate =
    (string.IsNullOrEmpty(ClientSigningCertificatePath)
    || string.IsNullOrEmpty(ClientSigningCertificatePassword))
    ? null : new X509Certificate2(ClientSigningCertificatePath,
    ClientSigningCertificatePassword);
  4. private static readonly X509SigningCredentials SigningCredentials =
    (ClientCertificate == null) ? null : new X509SigningCredentials(ClientCertificate,
    SecurityAlgorithms.RsaSha256Signature,
    SecurityAlgorithms.Sha256Digest);

进度大家得以用图片指示如下:

 

图片 7

X.509 证书 ,在如一下地点一样:
注册token、创立APP、导出公钥到Sharepoint、SharePoint服务器管理登记SPTrustedSecurityTokenIssuer. 
要让SharePoint和 非微软技术和谐共生“high trust” 情势下, 要求对JWT token
举办正确利用精通, 正确插入1个讲明nii 和nameid, 对token 使用X.509
证书签名。

8.其他阳台的JWT Libraries

想开提高开发功能,工具也是不可少的.  多量的JWT libraries可用. 
试试看下边.

 

在本身搞东搞西的研讨的时候, 作者注意到没有针对ACS验证格局:S2S完毕的库,
。。。。。。。

小手真疼,没人柔柔。。。。使用“低信任” 吧,别搞那么麻烦。

9.Office 365 APIs

Office 365,  挺好的O365
APIs,也不易,O365 API 有强劲的力量去建立Web Site、本地程序、 iOS、
Android和别的使用O365数额的应用程序,都以因此REST APIs 和专业的 OAuth. 
就像是前边大家解释的“低信任” APP 很不难采纳JWT library库一样, O365
APIs也是。

为立异验证的法门,现使用专业的OAuth 流.  同样 TokenHelper.cs, 
微软推出了Active Directory Authentication Library (ADAL) 用来让 JWT
使用Azure Active Directory 更有利,ADAL 库提供许多措施,其中囊括拿到access token, 这样就能在HTTP 头中添加 “Authorization: Bearer “. 
使用时无须要考虑X.509 证书或是修改现有的库, 你可以配备你的APP使用 Azure
Active Directory 然后调用 O365 API. 

此文对些有很深的钻研:, Call Multiple Services with One Login Prompt
Using
ADAL
,

经过应用Azure Active Directory,落成壹个APP,那些APP就是一个REST 调用,
很简单转成你的平台代码。

微软的“Microsoft Open Technologies group‘  已经建立了广大有关Active
Directory Authentication Library (ADAL) 的非微软平台的库: 

如若 O365 上开发APP,
直接用这个个API吧,简单地把部分ADAL示例转成以上的阳台的APP,那是多美好的一天。

10. 总结

最要紧的某些都曾经给您讲了, 解码token,拿到变量的值,还包涵 X.509
签名怎么办事,也告知您了 nameid 和nii 申明是怎么回事,

席卷如何运用FBA 和SAML 的用户本人都讲到了。 

新闻你就融洽看看啊:

JWT Specification
Draft

Understanding Authentication and Permissions with Apps for SharePoint
and Office

SharePoint 2013 User Profile Sync for Claims
Users

OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That
and What do I Need to
Know

PHP – Get users SID from Active Directory via
LDAP

SharePoint 2013: Perform operations on SharePoint Document Library from
PHP
site

Using SharePoint Apps with SAML and FBA Sites in SharePoint
2013

https://github.com/auth0/java-jwt – A Java JWT library

https://github.com/firebase/php-jwt – A PHP JWT library

https://github.com/michaelrhanson/jwt-js – JWT implemented in
JavaScript, used with Node.js

ADAL library for
Java

ADAL library for
Android

ADAL library for
iOS

ADAL library for
Node.js

相关文章