OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Schema for thought

I did some more thinking on the plane (and reviewed the Kerberos docs and
the recent SOAP client document posted by Tony) and thought I'd throw some
schema out to see if anything sticks.

My goal here was to try and think about the ID-FF AuthnRequest and the other
more general use cases and see what I could come up with to relate them. The
idea was also to create some more potential power in the SSO profiles for
browser/SP use cases but without adding anything that would complicate the
simple case.

What I ended up with as a straw man to play with was a hierarchy like this:

	--- ProxyAssertionRequest
	--- AuthnRequest

The basic request permits an entity to request an authentication assertion
and optionally specify the confirmation, conditions, and the required authn
context. (That seemed useful in cases where the underlying choice of
authentication approach might not be driven by the requester.) The idea with
this message was that it either lets a client say "I'm John, give me an
authn assertion".

The Proxy request (not at all what Liberty calls proxying now) lets a proxy
or intermediary say "I'm proxy Pete, give me an authn assertion for John"
and possibly include tokens that prove John is present. John is named in the
AuthorizationIdentity element, and the optional Impersonate flag might be a
way to indicate whether the proxy should be visible in the assertion as a
distinct entity. Without it, the impersonation is hidden.

None of this is precisely what a SSO AuthnRequest does (that message is
normally a challenge from a relying party), so I'm supposing that this be
left as a special case, but it permits that message to still leverage some
of the same functionality. So an AuthnRequest from an SP could say it wanted
stronger confirmation methods, specify other conditions (so it can pass
along the assertion perhaps), etc. which ID-FF doesn't support.

The rest is just me reworking the AuthnRequest, so an SP can control
authentication behavior, include an IDPList and proxying controls, specify
NameIDPolicy, the browser profile, etc. I'm not really thinking about what
this should all look like yet, just keeping it all in the picture for now.

I don't know how much of this we can specify for 2.0, but it seems worth at
least trying to do some of it. The simple cases if nothing else. As it is
there's not a clean way to get assertions except for browser SSO and
queries, and other kinds of clients and applications seem to be left in the

Flames welcome, this and the earlier note are just to try and bring some
concreteness to the discussions...

-- Scott

<element name="AssertionRequest" type="samlp:AssertionRequestType"/>
<complexType name="AssertionRequestType">
        <extension base="samlp:RequestAbstractType">
                <element ref="saml:ConfirmationMethod" minOccurs="0"/>
                <element ref="saml:Conditions" minOccurs="0"/>
                <element ref="samlp:RequestAuthnContext" minOccurs="0"/>

<element name="ProxyAssertionRequest"
<complexType name="ProxyAssertionRequestType">
        <extension base="samlp:AssertionRequestType">
                <element ref="saml:AuthorizationIdentity" minOccurs="0"/>
<element name="AuthorizationIdentity">
        <extension base="saml:SubjectType">
            <attribute name="Impersonate" type="boolean" use="optional"/>

<simpleType name="AuthnContextComparisonType">
    <restriction base="string">
        <enumeration value="exact"/>
        <enumeration value="minimum"/>
        <enumeration value="better"/>
        <enumeration value="maximum"/>
<element name="RequestAuthnContext">
                <element name="AuthnContextClassRef" type="anyURI"
                <element name="AuthnContextStatementRef" type="anyURI"
            <element name="AuthnContextComparison"
type="AuthnContextComparisonType" minOccurs="0"/>

<element name="AuthnRequest" type="samlp:AuthnRequestType"/>
<complexType name="AuthnRequestType">
        <extension base="samlp:AssertionRequestType">
                <element ref="samlp:NameIDPolicy" minOccurs="0"/>
                <choice minOccurs="0">
                    <element ref="ForceAuthn"/>
                    <element ref="IsPassive"/>
                <element ref="ProtocolProfile" minOccurs="0"/>
                <element ref="AssertionConsumerServiceID" minOccurs="0"/>
                <element ref="Scoping" minOccurs="0"/>
            <attribute ref="consent" use="optional"/>
<element name="NameIDPolicy" type="samlp:NameIDPolicyType"/>
<complexType name="NameIDPolicyType">
    <attribute name="Format" type="anyURI" use="optional"/>
    <attribute name="NameQualifier" type="string" use="optional"/>
    <attribute name="SPNameQualifier" type="string" use="optional"/>
<element name="ForceAuthn" type="boolean"/>
<element name="IsPassive" type="boolean"/>
<element name="ProtocolProfile" type="anyURI"/>
<element name="AssertionConsumerServiceID" type="string"/>
<element name="Scoping" type="samlp:ScopingType"/>
<complexType name="ScopingType">
        <element ref="ProxyCount" minOccurs="0"/>
        <element ref="IDPList" minOccurs="0"/>
        <element ref="ReqProviderID" minOccurs="0" maxOccurs="unbounded"/>
<element name="ProxyCount" type="nonNegativeInteger"/>
<element name="ReqProviderID" type="string"/>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]