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: AI: Changes to core for dest site first profiles


To support the dest site first POST profile in the proposal prepared by Prateek, Jahan, and myself, I developed a new Query type and
some related elements for addition to the protocol schema and associated text in core.

Based on core draft 03 posted by Eve, the changes go before line 1178, at the end of section 3.3. Eve, I have this in Word form
already formatted properly, so once something is voted on, I can just send you the Word document.

Prateek, you can send an email referencing the binding draft changes, and this text as the substance of the proposal.

-- Scott

3.3.6 Element <SSOQuery>

The <SSOQuery> element is used by a destination site to request that a source site authenticate a user and initiate single sign-on
(in effect asking for a single sign-on assertion). It is distinct from an <AuthenticationQuery> because an authentication query is
used to ask for evidence of previous authentications, while an SSO query initiates a new authentication interaction.

It has the complex type SSOQueryType, which extends QueryAbstractType by adding the following attributes and elements:

<Requester> [Required]
A string identifier that represents the destination site requesting authentication.

<Resource> [Optional]
An optional URI that represents the resource being accessed at the destination site.

<Profile> [Optional]
An optional URI that directs the source site to use a specific SSO profile. If provided, the source site MUST either use the
specified profile or signal an error.

<AssertionConsumerURL> [Optional]
An optional URL to direct the response or artifact produced by the source site. If provided, this URL MUST be used to deliver the
response or artifact.

<RelayState> [Optional]
An optional string that MUST be returned unmodified to the destination site by appending it as a parameter to the
<AssertionConsumerURL>. The length of the string specified in <RelayState> SHOULD be no more than 80 bytes in length.

The following schema fragment defines the <SSOQuery> element:
<element name="SSOQuery" type="samlp:SSOQueryType"/>
<complexType name="SSOQueryType">
	<complexContent>
		<extension base="samlp:QueryAbstractType">
			<sequence>
				<element ref="samlp:Profile" minOccurs="0"/>
				<element ref="samlp:AssertionConsumerURL" minOccurs="0"/>
				<element ref="samlp:RelayState" minOccurs="0"/>
			</sequence>
			<attribute name="Requester" type="string" use="required"/>
			<attribute name="Resource" type="anyURI" use="optional"/>
		</extension>
	</complexContent>
</complexType>

3.3.6.1 Element <Profile>

The <Profile> element is used to specify a SAML profile.

The following schema fragment defines the <Profile> element:

<element name="Profile" type="anyURI"/>

3.3.6.2 Element <AssertionConsumerURL>

The <AssertionConsumerURL> element is used to specify the address to which the source site should direct the artifact or response
produced during SSO.

The following schema fragment defines the <AssertionConsumerURL> element:

<element name="AssertionConsumerURL" type="anyURI"/>

3.3.6.3 Element <RelayState>

The <RelayState> element is used to communicate a string value from the destination site to the source site so that it will be
returned unchanged along with the authentication assertion. The length of the string SHOULD be at most 80 bytes. When <RelayState>
is present in an <AuthenticationRequest>, the source site MUST return it to the destination site by appending it as a parameter to
the <AssertionConsumerURL>. The source site MUST NOT modify the value.

The data in this element SHOULD be resistant to tampering by the user or the source site. It SHOULD NOT be possible to fool a
destination site into allowing an action solely on the basis of a change to the value. Use of a message digest or a hashed key into
a table are suggested.

The following schema fragment defines the <RelayState> element:

<element name="RelayState" type="string"/>



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