Advertisement
Guest User

Untitled

a guest
Jun 26th, 2017
52
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 3.54 KB | None | 0 0
  1. The Identity Metasystem specification is designed to be both flexible and complete. It builds on existing web standards such as WS-Policy, WS-Security, WS-SecurityPolicy, and WS-Trust to define a secure environment for identity federation between service providers and consumers.
  2.  
  3. A Relying Party (RP) wishes to restrict access to a web resource by requiring the presentation of one or more security tokens, encapsulated by an Information Card (IC). A user must possess an appropriate IC that satisfies the RP's required claims. Note that the IC itself does not make claims, but rather gives the user's Identity Selector a reference to claims it knows an Identity Provider can satisfy.
  4.  
  5. The RP specifies its claim requirements by including the $<$sp:IssuedToken \ldots$>$ element in its security policy. This element requires three children specifying 1) the Issuer of security tokens, which can be self-issued ($<$sp:Issuer \ldots$>$), 2) the desired claim types (by extension of $<$wst:Claims \ldots$>$), and 3) the security policy of the RP (extension of $<$wsp:Policy \ldots$>$).
  6.  
  7. From a user's perspective, the main unit of the Metasystem is the Information Card (IC). This is given to a user from an Identity Provider (IP) to specify that the IP will issue certain tokens for the user, representing his or her digital identity with that IP. By keeping a local collection of ICs, a user's Identity Selector (IS, the software component which handles the storage of ICs and transfer of tokens between IPs and RPs) can automatically find ICs that match a certain RP's token policy. The user can visually select one IC from any which match the requirements, allowing the IS to obtain security assertions from the IP, which are sent to the RP.
  8.  
  9. The tangible manifestation of the IC is an xml document given to a user from the IP, with the top-leve element $<$ic:InformationCard \ldots$>$. It has child fields such as $<$ic:CardName$>$, $<$ic:CardImage$>$, $<$ic:Issuer$>$, $<$ic:PrivacyPolicy$>$, $<$ic07:IssuerInformation$>$, $<$ic:TimeIssued$>$, and $<$ic:TimeExpires$>$. It also specifies a $<$ic:TokenServiceList$>$ which is a list of URIs where the IS can retreive security assertions. There are the $<$ic:SupportedTokenTypeList$>$ and $<$ic:SupportedClaimTypeList$>$ to specify what information this IC represents. Finally, the IC can add the $<$ic:RequireAppliesTo$>$ field to specify that token requests must include the RP for which they are intended.
  10.  
  11. The transfer of tokens between the user holding an IC (through an IS) and the IP is handled through $<$wst:RequestSecurityToken \ldots$>$ and $<$wst:RequestSecurityTokenResponse \ldots$>$ elements. Since this process follows predefined WS-Trust standards and we will not modify it, we will not discuss it in detail here.
  12.  
  13. Similarly, passing tokens from the IS to the RP follows the existing wst protocol, but it is in this interaction where we will make an extension. To allow a user to require tokens from a RP before releasing their own, we will send a response notifying the RP of our policy requirements, and it will mirror the process by which the RP requests tokens. The RP will be configured to automatically respond to these requests with preconfigured ICs, such as proving accreditation from the Better Business Bureau. In this manner the user's IS will have to take on some functionality found in the RP, and the RP will need some of what the IS provides a user.
  14.  
  15. \begin{figure}[h]
  16. \begin{center}
  17. \includegraphics[width=60mm]{infocardsystem.png}
  18. \end{center}
  19. \caption{The infocard system}
  20. \label{fig:infocard}
  21. \end{figure}
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement