[Concordia] Cardspace support for Authn Mechanism Policy
Paul Madsen
paulmadsen at rogers.com
Mon Jan 7 16:05:52 EST 2008
Tony, can you expand on what the issue is?
I've been going on the assumption that the STS would communicate the
authn method to the RP through whatever mechanism the returned token
afforded, e.g. SAML 1.1 authnmethod attribute or SAML 2.0 authn context ....
The issue has been how things work in the other direction (i.e. from the
RP to the STS) and I believe we've come to the conclusion that we need
to define some claim types to make things work in the near term.
paul
Anthony Nadalin wrote:
>
> a) User agent/browser invokes RP via HTTP/S GET
> b) Page is returned with the Cardspace tag data (if present)
> b) User agent/browser determines that a selector is installed (via
> object tag info from page returned) and finds the
> registered selector
> c) User agent invokes selector and passes data from object tag (i.e
> policy, claims, etc)
>
> interface IInformationCardSigninHelper
> { string issuer; // URI specifying token issuer
> string issuerPolicy; // MetadataExchange endpoint of issuer
> string tokenType; // URI specifiying type of token to be requested
> string [] requiredClaims; // Array of required claims
> string [] optionalClaims; // Array of optional claims
> string privacyUrl; // URL of the privacy policy of the site
> string privacyVersion; // Version number of the privacy policy
> boolean isInstalled; // True when an Identity Selector is available //
> to the browser }
>
> d) Selector optionally retrieves WS-SecurityPolicy through
> WS-MetaDataExchange if the issuerPolicy is present
> e) Selector optionally parses <IssuedToken> from within security policy,
> f) Selector matches available card metadata with that of the required
> claims from the RP
> g) user chooses from available candidate cards from the selector
> h) Selector composes RST to send, copies any info from the
> <IssuedToken>/<RequestSecurityTokenTemplate> into the RST
> i) STS returns RSTR
> j) Selector parses RSTR and inserts token in page and posts the page
> back to RP
>
> So just a policy via MEX will not be enough, this would take a policy
> that the RP indicates on how one contacts the STS and a way for the RP
> to know that this was the method chosen, most likely via claim.
>
>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
>
> Inactive hide details for Paul Madsen ---12/13/2007 01:41:12 PM---As
> discussed on callPaul Madsen ---12/13/2007 01:41:12 PM---As discussed
> on call
>
>
> From:
> Paul Madsen <paulmadsen at rogers.com>
>
> To:
> "community at projectconcordia.org" <community at projectconcordia.org>
>
> Date:
> 12/13/2007 01:41 PM
>
> Subject:
> [Concordia] Cardspace support for Authn Mechanism Policy
>
> ------------------------------------------------------------------------
>
>
>
> As discussed on call
>
> Forgetting for a moment the SAML/WS-Fed side of things, I'm trying to
> understand how an Infocard RP can dictate the authentication mechanism
> used by the client to authenticate to a managed card - this necessary if
> a SAML IDP is going to act as an Infocard RP.
>
> From ISIP v1.0 [1]
>
> "Every information card issued by an identity provider MUST include an
> ordered list of IP/STS endpoints, and the corresponding credential type
> to be used, for requesting tokens. The list MUST be in a decreasing
> order of preference. For each endpoint, the required credential type
> implicitly determines the authentication mechanism to be used."
>
> Example syntax
>
> <ic:TokenService>
> <wsa:EndpointReference> ... </wsa:EndpointReference>
> <ic:UserCredential>
> <ic:X509V3Credential>...</ic:X509V3Credential>
> </ic:UserCredential>
> </ic:TokenService>
>
> Note that a card can have more than a single supported authentication
> mechanism.
>
> So this is how the IP/STS specifies for each of its managed cards how
> authentication 'to the card' can happen.
>
> The question remains as to how the RP indicates its requirements of the
> authentication mechanism to either or both of the selector and IP/STS,
>
> Also from ISIP
>
> "A relying party specifies its security token requirements as part of
> its security policy using the primitives and assertions defined in
> [WS-SecurityPolicy]. The primary construct in the security policy of the
> relying party used to specify its requirement for a security token from
> an identity provider is the <sp:IssuedToken> policy assertion."
>
> From WS-SecurityPolicy (Appendix B) [2]
>
> "The Issued Token policy assertion includes two parts:
> 1) client-specific parameters that must be understood and processed by
> the client and
> 2) STS specific parameters which are to be processed by the STS."
>
> "The client-specific parameters of the Issued Token policy assertion
> along with the remainder of the server policy are consumed by the
> client. The STS specific parameters of the Issued Token policy assertion
> are passed on to the STS by copying the parameters directly into the RST
> request sent by the Client to the STS"
>
> The parameters to be included in the RST request are communicated to the
> client in a <RequestSecurityTokenTemplate> element, syntax like
>
> <sp:IssuedToken>
> <sp:Issuer>wsa:EndpointReferenceType</sp:Issuer>
> <sp:RequestSecurityTokenTemplate>
>
> </sp:RequestSecurityTokenTemplate>
> </sp:IssuedToken>
>
> If the 'client-specific' info in the <IssuedToken> were to specify
> required authentication mechanisms, then Cardspace could match those RP
> requirements against its available cards and their associated
> <TokenService> elements
>
> So, AFAICT, the sequence is something like
>
> a) RP invokes Cardspace, provides metadata address
> b) Cardspace retrieves WS-SecurityPolicy through metadata retrieval
> c) Cardspace parses <IssuedToken> from within security policy
> d) Cardspace matches available cards against the client specific info
> in the RP <IssuedToken> (matching can include authentication mechanism?)
> e) user chooses from available candidate cards
> f) Cardspace composes RST to send, copies any info from the
> <IssuedToken>/<RequestSecurityTokenTemplate> into the RST
>
> What seems strange is that, if the above is how it works , the RP would
> explicitly indicate its requirements of authentication in the
> <IssuedToken>, but the requirements would be only implicitly passed onto
> the IP/STS through the card selection?
>
> Alternatively, were the RP to express its requirements within the
> <RequestSecurityTokenTemplate>, then the selector would be unable to
> match cards based on those requirements.....
>
> The other direction seems straightforward ......
>
> paul
>
> refs
>
> [1] -
> http://download.microsoft.com/download/1/1/a/11ac6505-e4c0-4e05-987c-6f1d31855cd2/Identity-Selector-Interop-Profile-v1.pdf
> [2] -
> http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf
>
> --
> Paul Madsen e:paulmadsen @ ntt-at.com
> NTT p:613-482-0432
> m:613-282-8647
> aim:PaulMdsn5
> web:connectid.blogspot.com
>
> _______________________________________________
> Community mailing list
> Community at projectconcordia.org
> http://lists.projectconcordia.org/mailman/listinfo/community
>
> Participating in this discussion list does not grant any intellectual
> property rights or any commitment by the participants of the content
> discussed to any organization.
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.17.9/1197 - Release Date: 25/12/2007 8:04 PM
>
--
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-282-8647
aim:PaulMdsn5
web:connectid.blogspot.com
More information about the Community
mailing list