[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: draft minute notes for Wednesday AM
Here are the notes I collected on this morning's session. --jl Minutes for Wednesday morning session of SSTC meeting, collected by John Linn Rob Philpott called the session to order, and Prateek Mishra collected attendance. Discussion of W-5b: SOAP Client Profile (Mike McIntosh): The document covers 3 scenarios: · SOAP requestor of SAML assertion to be sent to service provider; · proxy-based SOAP request for SAML assertion, where proxy forwards assertion; · service requests SAML assertion for SOAP client For each case, the WSS SAML token profile is used to protect the SAML assertion. The client authenticates to the service provider using some mechanism other than SAML. Tony observed that this proposal represented one of many possible integration approaches. Scott observed that the use of the SAML token profile to protect the returned assertion appeared unusual. Irving Reid observed that credentials in WSS messages seem to serve two distinct purposes: message protection and/or proof of identity, and that this overlap can be confusing. Towards the end of Sec. 3, Ron Monzillo observed that step 2 might represent an appropriate use of the SAML Token profile, rather than step 5 as described. Per steps 4 and 5, Irving commented that it seemed strange to use SOAP header elements; Tony Nadalin asserted that it appeared natural for use within a WSS environment. Generally, there was controversy about the relative merits of applying SOAP header elements vs. layers enclosed within SOAP messages. Irving presented a diagram for a candidate flow, in which a SOAP client requests an operation from an SP, carrying an abstract ticket to authenticate itself. The SP, in turn, invokes an IDP to obtain an assertion. Irving recommended that these elements be placed in the SOAP body rather than the header. Mike compared this to his proposal, where the client authenticates using WSS. Irving believed that, in certain deployment models, WSS wrappers might be applied and removed at lower implementation layers, making it difficult to also use the WSS layer to provide the functions being considered. Irving observed that Mike's model appears to be oriented to a relatively low-function SP, performing only limited processing and acting as a pass-through for unmodified data elements. Tony sees some similarity between aspects of Mike's proposal and Scott's proxy materials. Bob Morgan was unclear as to what models this proposal would enable which are not already possible within SAML. Rob noted that this adds specification for the use of authentication based on WSS. Scott was not sure as to whether the SSTC should profile WSS usage. Prateek asked about next steps, based on these proposed use cases and solution elements. Irving believed that the translation of one WSS message to another is properly a WSS profiling activity, rather than a SAML activity; Tony believed that profiling WSS, carrying SAML assertions, was no less appropriate as a SAML activity than profiling HTTP-based SSO protocols. Eve asked, what would this solution provide that composition of existing elements couldn't offer? One possible value is that it provides a push model. Prateek asks whether the TC will accept the use case; Eve believes that the TC does not yet fully understand the proposal and its benefits, and asks for timely clarification. Given the SAML 2.0 schedule, she further observes that such work may need to be considered within a subsequent phase. Scott believes that existing elements (possibly with certain extensions, as to request a token for another identity) can satisfy the first two proposed functional scenarios, assuming that requests are made within the SAML protocol. Eve Maler suggests (and Prateek concurs) that the proposal's proponents should provide additional use case motivation and clarification for follow-up discussion (possibly tomorrow), in the context of SAML and the WSS SAML token profile. Scott and Irving also plan to contribute to this analysis, considering both aspects of SAML 1.1 and of current SAML 2.0 work in progress. Discussion of W-25: Kerberos Support (John Hughes, Tim Alsop): Two documents have been offered, per restructuring discussed on TC con call: · Generalized AuthnRequest Protocols and · Kerberos SAML Profiles. The Kerberos-specific profile needs an updated solution proposal, which is hopefully to be provided this week. A user's workstation runs code causing the described SAML service (which corresponds to the SAML authority as described in other terminology) to return an AuthnResponse, using Kerberos to protect the interaction with that service. While Kerberos can be used for a number of functions, the proposal emphasizes its use to securely pass a user identity to the SAML responder via the SAML service. Among several other uses, Kerberos can also be considered as an alternative to SSL to provide a secure channel. Noted: Kerberos TLS ciphersuite definition exists, but has not been widely implemented. John Linn asked whether it was within SSTC scope to define approaches to provide secure channels, vs. recommending that secure channels be provided at layers below SAML? The primary use case concerns use of a Kerberos ticket as input to obtain a SAML assertion, reflecting the identity obtained from the ticket. The proposed approach establishes a GSS-API security context to the SAML service, carrying GSS tokens within a variety of protocols; identified customer requirements have not been SOAP-oriented. Jeff Hodges suggested that this use case be treated generically, also accommodating other mechanisms than Kerberos. Schema elements were proposed to represent DCE/Microsoft privilege attribute certificate (PAC) contents within attribute statements. Name identifier forms were also proposed to represent Kerberos principal names; following recent reconsideration, proponents now suggest that the Kerberos realm be included as a qualifier to the individual principal name. Hal Lockhart asked whether UUIDs should be represented. Identified outstanding issues include mapping to Microsoft PAC data, how and why to bind Kerberos credentials to SAML assertions (e.g., including Kerberos keys as confirmation methods), additional detail on Kerberos/GSS-API bindings, and appropriate use of existing Liberty, WSS, and Microsoft Passport Kerberos-related standards and drafts. In future, also, SAML and Kerberos might be combined as a means to establish cross-realm trust. Scott raises the use case of incorporating forwardable Kerberos tickets within attributes. Jeff Hodges clarifies that Liberty is not doing work specific to Kerberos, but that its ongoing SASL work can accommodate Kerberos along with other mechanisms. Suggested next step: elaborated proposal could be discussed at upcoming focus call. Rob questions whether this will fit into the SAML 2.0 schedule. Mike Beach suggested that it could be useful for the SSTC to define mappings between Kerberos and SAML data elements. Prateek introduced discussion of a pending LECP motion, containing the following elements: · Adopt LECP solution proposal, Draft 5, 2 Jan 04 · Adopt PAOS+LECP solution proposal, Draft 1, 8 Jan 04 · Integrate into SAML 2.0 Bindings and Profiles specification Ron questioned whether these elements were necessarily within SSTC scope; Scott believes that they are appropriate profiles to consider for SSTC purposes. To this point, SAML has not specified that particular profiles must be implemented for conformance purposes. Prateek observed that conformance criteria are likely to become more complex for SAML 2.0. Tony indicated that he found the supporting use case for PAOS to be unclear. Frederick Hirsch suggested that it allowed use with non-SOAP service providers, and that it was compatible with operational models common in mobile environments. Greg Whitehead commented that LECP offers particular value in multi-IDP scenarios, taking advantage of information resident on mobile terminals. Attendees indicated that they perceive existing and emerging interest in SOAP-capable mobile terminals, and it was suggested that definition of a standard approach for their support would be useful. Mike McIntosh and Tony Nadalin object to the motion, particularly questioning its inclusion of PAOS. Prateek takes a vote of attendees. 11 yes, 7 abstain, 4 no; vote passes on simple majority. The morning session was adjourned at 12:16 PM.