SAML标准&协议(二)

日期: 2007-12-25 来源:TechTarget中国

  SAML就是为了解决这个问题。

  在联邦环境中,通常有下面的3种实体:

  Subject主题):Subject是SAML实体中的第一个重要的概念,Subject包括了User、Entity、Workstation等能够象征一个参与信息交换的实体。

  RelyingParty信任方):SAML中的ServiceProvider角色,也就是提供服务的一方。

  AssertingParty断言方):SAML中的IdentityProvider角色,用于提供对主题的身份信息的正确的断言,类似一个公证机构。

  我们看看联邦环境的一个场景:

  假设有一个Peter(Subject)的法国公民,他需要访问比利时(ServiceProvider),他在比利时机场被要求提供身份信息,Peter提供了欧盟(Federation)的通行证件,随即,这个通行证件在比利时机场被审核,或通过计算机送到欧盟身份认证中心(IdentityProvider),该中心有一个由所有欧盟国家共同建立的公民数据库,中心审核了Peter的身份信息,并断言“Yes,HeisPeterFromFrance”,于是,Peter得到礼貌的回应“欢迎光临比利时”。

  如果你将欧盟看作是一个联邦环境,你会发现上面的场景跟在联邦环境应用SAML很相似。

  在联邦环境下,任何需要授权访问的服务都需要知道服务请求方的身份主题信息(Whoareyou),服务提供方(ServiceProvider)不负责审核用户的身份信息,但它依赖于1个甚至多个IdentityProvider来完成此任务,见下图。

  1个IdnetityProvider可以被多个ServiceProvider共享,当然,共享的前提是建立信任关系(即ServiceProvider要信任IdnetityProvider),就好比如,如果比利时(ServiceProvider)需要开放对欧盟国家成员访问,它信任欧盟的IdnetityProvider,它信任欧盟的IdnetityProvider的任何判断,包括”HeisPeterFromFrance”。至于是否让Peter入境,那是受权限策略的控制(注意SAML同样对Authorization断言做了标准化,此处,我们仅仅关注Authentication)。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐

  • 在SOA和云中我们真的需要身份传递吗?

    IT开发者,尤其IT安全专家已经为创建一个企业级的身份控制机制奋斗了多年。在这一领域最广为人知的倡议和模型就是单点登陆。

  • 云单点登录升级便利牺牲安全?

    对于服务提供商来说,管理单一云服务安全富有挑战性,更不必说多个云服务了。但是很多企业正在从事多个云战略,似乎又与客户不复杂的且防弹的安全策略相冲突。

  • OAuth协议获得网络服务安全协议授权

    使用基于令牌(token-based)的安全模式,导致OAuth(开放授权)协议最近在安全和服务界备受瞩目。尽管OAuth并不是人人皆知的词语,但是也会逐渐为人们所熟知。最著名的OAuth应用就是Facebook平台。

  • 从SOA到云计算:软件服务安全进化

    在某种程度上,云安全的状态取决于对其的观点。危言耸听者(那些半吊子家伙们)将其看作是“狂野西部(Wild West)”,而云支持者又认为这些关注点是过分夸大的。