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

 


Help: OASIS Mailing Lists Help | MarkMail Help

samldemotech message

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


Subject: RE: ? on AuthnRequest


> Yes, I had been counting on running a separate instance of our IDP for
> the optional use case (and configuring the default name format
> appropriately in that instance).

[RSP] Does that mean we've got to configure our SP to know about 2 separate IDP's for your site and then pick one based on the scenario?  Ugh - that really complicates the configuration if everyone does that. Does this mean you have 2 different EntityID's based on which one responds?  This is more configuration than we had planned for.

We have been assuming that there'd just be a SINGLE IDP SSO endpoint for each vendor.  That is, if we were using metadata, there is just one EntityDescriptor for each vendor, each with an IDPSSODescriptor that has one <SingleSignOnService> element with the endpoint defined.  

Or are you handling that behind your SSO service endpoint and it is transparent to everyone else?

> 
> I don't mind passing the requested name format in the AuthnRequest if
> that helps other folks, though.
> 
> -Greg
> 
> On Jan 31, 2005, at 1:07 PM, Ciochon, Robert wrote:
> 
> > Thanks for laying this out Rob. Comments and feedback?
> >
> > Regarding which demo scenario is being run, we had decided on one of
> > the calls that there would be 2 lists of idP's used on the SP, one for
> > the base use cases and one for the optional. Selecting from a
> > particular idP list defines which use case, not the user name. It
> > sounds like you have a problem doing itthis way. Anyone else?
> > Regards,
> > Bob
> >
> >
> > From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
> >  Sent: Monday, January 31, 2005 10:09 AM
> > To: samldemotech
> > Subject: ? on AuthnRequest
> >
> >
> > The interop spec doesn't say anything about what we'll be sending in
> > the AuthnRequest messages of the demo scenarios. Let me throw out
> > what I think we should do and see if it sticks.
> >
> >
> >
> > AuthnRequest:
> >
> >  - Attributes from RequestAbstractType:
> >
> > o ID: NCName string; required by SAML - MUST be sent
> >
> > o Version: string; required by SAML; value = "2.0" - MUST be
> > sent
> >
> > o IssueInstant: xs:dateTime; required by SAML - MUST be sent
> >
> > o Destination: URI; required by SAML when using HTTP Redirect
> > or POST bindings - MUST be sent
> >
> > o Consent: values from spec - MUST NOT be sent
> >
> > - Elements from RequestAbstractType:
> >
> > o <saml:Issuer>: IssuerType - required for all profiles we're
> > using - MUST be sent
> >
> >  Format must be omitted or must be set to
> > "urn:...:nameid-format: entity".
> >
> >   NameQualifier, SPNameQualifier, and SPProvidedID - MUST NOT
> > be sent
> >
> > o <ds:Signature> - MUST NOT be sent
> >
> >   Note that the redirect binding will sign the URL parameters
> > as defined in the spec, so the message itself should not include a
> > signature
> >
> > - AuthnRequest-specific Attributes :
> >
> > o ForceAuthn - MUST NOT be sent
> >
> > o IsPassive - MUST NOT be sent
> >
> > o AssertionconsumerServiceIndex - MUST NOT be sent
> >
> > o AssertionConsumerServiceURL - MUST NOT be sent
> >
> > o ProtocolBinding - MUST NOT be sent
> >
> > o AttributeConsumingServiceIndex - MUST NOT be sent
> >
> > - AuthnRequest-specific Elements :
> >
> > o <saml:Subject> - MUST NOT be sent
> >
> > o <saml:NameIDPolicy> - MUST be sent
> >
> >  Format: MUST NOT be included
> >
> >  AllowCreate flag is "true"
> >
> >  SPNameQualifier - MUST NOT be sent
> >
> > o <saml:Conditions> - MUST NOT be sent
> >
> > o <RequestedAuthnContext> - MUST NOT be sent
> >
> > o <Scoping> - MUST NOT be sent
> >
> >
> >
> > The only item I debated about was the NameIDPolicy. AllowCreate must
> > be true for the optional use cases, but when the SP sends the user to
> > the IDP it normally doesn't know which use case is being run. I
> > believe that is controlled by what user account the use logs in with
> > at the IDP. Alice, Bob, and Charlie are for the base use case and
> > <vendor>user<n> (e.g. rsauser1) users are for the optional use cases.
> >
> >
> >
> > So we could have defined the <NameIDPolicy> as follows:
> >
> >  o For the base use case:
> >
> >  Format: urn:...:nameid-format:X509SubjectName
> >
> >  AllowCreate flag is omitted or must be set to "false"
> >
> >  SPNameQualifier - MUST NOT be sent
> >
> > o For the optional use case:
> >
> >  Format: urn:...:nameid-format:persistent
> >
> >  AllowCreate flag is "true"
> >
> >  SPNameQualifier - MUST NOT be sent
> >
> > But this means the SP has to know which demo the user is running
> > before they are sent to the SP. Our SP can't easily do this.
> >
> >
> >
> > Comments/Questions/Complaints?
> >
> >
> >
> > Rob Philpott
> > Senior Consulting Engineer
> > RSA Security Inc.
> > Tel: 781-515-7115
> > Mobile: 617-510-0893
> > Fax: 781-515-7020
> >  mailto:rphilpott@rsasecurity.com
> >
> >



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