[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: AssertionRequest | | --- 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 cold. 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"> <complexContent> <extension base="samlp:RequestAbstractType"> <sequence> <element ref="saml:ConfirmationMethod" minOccurs="0"/> <element ref="saml:Conditions" minOccurs="0"/> <element ref="samlp:RequestAuthnContext" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> <element name="ProxyAssertionRequest" type="samlp:ProxyAssertionRequestType"/> <complexType name="ProxyAssertionRequestType"> <complexContent> <extension base="samlp:AssertionRequestType"> <sequence> <element ref="saml:AuthorizationIdentity" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> <element name="AuthorizationIdentity"> <complexType> <extension base="saml:SubjectType"> <attribute name="Impersonate" type="boolean" use="optional"/> </extension> </complexType> </element> <simpleType name="AuthnContextComparisonType"> <restriction base="string"> <enumeration value="exact"/> <enumeration value="minimum"/> <enumeration value="better"/> <enumeration value="maximum"/> </restriction> </simpleType> <element name="RequestAuthnContext"> <complexType> <sequence> <choice> <element name="AuthnContextClassRef" type="anyURI" maxOccurs="unbounded"/> <element name="AuthnContextStatementRef" type="anyURI" maxOccurs="unbounded"/> </choice> <element name="AuthnContextComparison" type="AuthnContextComparisonType" minOccurs="0"/> </sequence> </complexType> </element> <element name="AuthnRequest" type="samlp:AuthnRequestType"/> <complexType name="AuthnRequestType"> <complexContent> <extension base="samlp:AssertionRequestType"> <sequence> <element ref="samlp:NameIDPolicy" minOccurs="0"/> <choice minOccurs="0"> <element ref="ForceAuthn"/> <element ref="IsPassive"/> </choice> <element ref="ProtocolProfile" minOccurs="0"/> <element ref="AssertionConsumerServiceID" minOccurs="0"/> <element ref="Scoping" minOccurs="0"/> </sequence> <attribute ref="consent" use="optional"/> </extension> </complexContent> </complexType> <element name="NameIDPolicy" type="samlp:NameIDPolicyType"/> <complexType name="NameIDPolicyType"> <sequence/> <attribute name="Format" type="anyURI" use="optional"/> <attribute name="NameQualifier" type="string" use="optional"/> <attribute name="SPNameQualifier" type="string" use="optional"/> </complexType> <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"> <sequence> <element ref="ProxyCount" minOccurs="0"/> <element ref="IDPList" minOccurs="0"/> <element ref="ReqProviderID" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> <element name="ProxyCount" type="nonNegativeInteger"/> <element name="ReqProviderID" type="string"/>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]