[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [security-services] Draft minutes for Tuesday PM
OASIS Security Services TC
Feb. 3, 2004 Afternoon
On the phone: Emily Xu, Tony Nadalin
W-1: Session Support, John Kemp
- Reference:: http://lists.oasis-open.org/archives/security-services/200402/msg00013.html
- Proposal 1: Use assertion ID and validity period to represent the session and validity period.
- Hal: Assertion ID is not really session ID, but used to identity session by the session authority.
- No separate piece of XML to represent session in SAML protocol.
- Authentication authority and session authority are the same.
- Hal: Neither proposal extends life of session.
- Scott: SP can treat new assertion as a continuation of a session if it wants. One purpose for relay state: session token.
- Mike B: Use case for session with multiple authentication assertions? Hal: Sign on with password then later with certificate.
- Ron: Does session have to be bound to an authentication event?
- Hal: Objective is dynamic session termination.
- Scott: Not a general purpose solution for accounting, message protection (e.g. Kerberos).
- Validity period discussion
- Hal: In artifact & post profile, assertion validity max time to initiate SSO (short lived), not length of session.
- Prateek: Meant to be an introduction protocol.
- Rob: Use local session policies after using assertion to initiate session.
- Steve: Have to remember something about the session, e.g. assertion ID, and have some expiration on the stored data.
- Scott: Always had IssueInstance for freshness control.
- Mike B: Concern about SPs ignoring assertion/session expiration.
- Prateek: IdP control over lifetime of assertion important.
- Mike B: SPs have specific timeouts; user still logged in at IdP; need to force re-authentication. Hal: can be handled by proposals.
- Prateek: Why not propagate session lifetime as well as assertion validity?
Hint vs. enforce. Conformance behavior for SP.
- Logout Proposal: Send logout message if principal logs out, session authority notifies participants. (ID-FF 1.2)
- Ron: If message doesn't go through, can't log out. Best effort.
- Scott: IdP batches all assertions it considers a session.
- Scott: Case where rule can't exist: Web browser and phone log in; different sessions.
- Hal: Participants should agree one way or another but be consistent.
- Hal: SP can ask session to logout, SA can tell SPs when session is logged out.
- Discussion on whether a SP can say "no" to a logout.
- Hal: Session only for those who explicitly asked for it, so should only participate if can honor logout.
- Rob: Hand off session to a legacy system with no way to end legacy session.
- Discussion of polling for validity vs. waiting for logout messages.
- Hal: Either IdPs have to keep track of which SPs have been given assertions, or SPs need to handle logouts for sessions they don't know about.
- John: Could do what Liberty does with Session ID in authentication assertion.
- Ron: What is SP state for session? Scott. etc: Assertion ID, maybe original assertion,
maybe related local state. Hal: need to track touch time if care about idle time.
- Motion by John: Incorporate ID-FF v1.2 logout protocol, with extension into SAML v2.0.
- Seconded by Hal.
- Discussion
- Hal: Concern with using same logout message with different semantics.
- Mike B: one way is logout notification, other way is logout request.
- No objections.Motion carries.
- Hypothetical motion: Use assertion ID as the session identifier.
- Mike B: Why not use Liberty concept of session ID in the assertion?
- John: More simple to use existing assertion ID than introduce additional elements.
- Scott: Some problems with ID-FF sessions; required some cleanup; clean now.
- Mike B: Would like convergence between Liberty and SAML.
- John: Liberty providers would implement SAML 2.0.
- Compromise proposal: use assertion ID and include session ID in authentication statement?
- Ron: Prefer in Subject statement for other types of statements; John: was there originally.
- Timeout Proposal (Hal): One max idle timeout for all SPs; individual shorter SP timeouts.
- Central session authority (SA) keeps track of session activity. All SPs report touch time to SA (one way). SA keeps latest touch time.
- If max idle timeout occurs, session logged out for all SPs.
- If individual SP timeout occurs, session logged out for that SP.
- R.L. "Bob": SA should notify SP if the session doesn't exist anymore. Ron: Touch time notification could need a response sometimes.
- SA periodically scans touch times to find those older than max global timeout or individual SP timeout, then sends logout requests to SPs.
- Steve: Desire more on demand update of touch time. User sends a browser request that exceeds local SP idle timeout; ask SA the last touch time, SA might poll other SPs.
- Hal: concern about scaling
- Irving & Scott: requirement for front channel binding.
- Greg: Hybrid approach: SPs report touch time only when they see a user.
- Steve: Issue with resource access through components with no SAML knowledge.
- No agreement on next step.
W-5: SSO Profile Enhancements, Prateek Mishra
- Proposal 1: Replace SAML 1.1 profiles with ID-FF AuthnRequest: SP->IdP; AuthnResponse: IdP->SP
- Proposal 2: Accept materials in section 3.2 for abstract AuthnRequest and AuthnResponse protocol.
- Map AuthnRequest/Response to existing web SSO profiles.
- John H: Not clear can use AuthnRequest for artifact. Scott: artifact represents a response.
- Scott: Can't divorce AuthnResponse from the Liberty assertion.
- Scott: Review of AuthnRequest schema
- Extension: allows derivation of new types from AuthnRequest.
- ProviderID: superfluous now that Issuer is in the SAML 2.0 request; will be dropped.
- AffliationID: request authentication as part of an affiliation.
- R. L. "Bob": collection of SPs - implicit SAML support requirement.
- NameIDPolicy: enumerated type -- desired name ID and federation operations,
e.g. use existing federated ID, but don't establish a new federation; Needs to be generalized for SAML.
- Jeff: Need to be careful to have true convergence with Liberty, backwards compatibility with existing Liberty values.
- Discussion about increasing protocol size. Agreement for now to keep one document for assertion and protocols.
- ForceAuthn: IdP should try to interact with principal to re-authentication
- IsPassive: don't interact with principal. Discussion of relation with ForceAuthn.
- ProtocolProfile: which profile to use for the request; decomposes request and response profiles, but different profiles not used by anyone?
- AssertionConsumerServiceID: used to identity the AssertionConsumerService URL; SP can have multiple such URLs. Example: regional consumers.
- RequestAuthnContext: authentication requirements; statements of policies and procedures
- RelayState: now in base request type.
- Scoping: proxy use case
- Consent: have obtained user consent for operation.
- Liberty says request should be signed but does not require it.
- Review of AuthnResponse schema
- Extension
- ProviderID -> Issuer
- RelayState
- Carries assertion as per base type.
- Liberty requires assertions to be signed for use as security tokens. Not practical
to sign both assertion and response.
- Liberty assertion contains InResponseTo vs. SAML response.
- Liberty assertion uses Audience (name of consuming SP) vs. SAML response Recipient (SP location URL).
- Prateek moved to accept Proposal 1 and 2. Eve seconded.
- Discussion
- Tony: why totally get rid of SAML 1.1 profiles?
- Prateek: Adopt abstract AuthnRequest-Response and then revisit concrete implementations.
- Tony: concern about existing implementations. Irving: how different from existing implementations?
- Scott: resulting architecture not too different.
- Charles: Example of post profile, what would change would be response in the post.
- Charles: One motivation is solution of "destination-first" problem? Prateek: yes.
- Motion is to accept this as a starting point for subsequent work.
- Motion carries by unanimous consent.
W-5a: Enhanced Client Profiles, Frederick Hirsch
- Goal: Bring solutions enabled by SAML to a wide variety of devices
- Enhanced client or proxy (ECP): IdP- --- ECP ---- SP
- ECP profile:
- ECP request to SP
- SP requests authn in response
- ECP gets assertion from IdP
- ECP returns assertion to SP
- Profiles:
- Legacy-SP (HTTP only for SP) = LECP
- Reverse HTTP SOAP binding PAOS + LECP = PECP
- PAOS: reverse-HTTP binding for SOAP, solicit-response message exchange pattern.
- PAOS + LECP: eliminates custom AuthnRequest/Response envelopes, uses custom SOAP headers
- Issue: use of PAOS + LECP as a general mechanism for SOAP clients.
- Question on how agnostic proposal is to SOAP version. Scott: do we need normative spec language for SOAP 1.2?
- Jeff:: what is depth of penetration of SOAP 1.2 in the marketplace?
- Proposals:
- Adopt LECP solution (draft 5).
- Adopt PAOS + LECP solution (draft 1).
- Integrate into SAML 2.0 bindings and profiles specs.
- Frederick moved to accept proposals; John K. seconded.
- Discussion of relation between these proposals and other proposals to be discussed later in this F2F.
- Motion tabled. Discussion to resume tomorrow.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]