[Concordia] Notes from 10 Jan 2008 Concordia call

Tue Jan 22 04:45:29 EST 2008

Hi the Concordia community,

Few days ago, I wrote to Eve to talk about SAML2 and WS-Fed chaining. I 
didn't know how I could contribute to Concordia and also if I my works 
would be interesting for the community. She gave me a positive echo. I 
think my works are closed to your scenario11 and what you call "tunneling".

I made a basic comparison of SAML2 and WS-Fed1.1:  
http://mikaelates.blogspot.com/2007/12/saml2-and-ws-federation11b.html.
The interoperability is based on a third party in charge of the 
interoperability process and trusted by both the assertion/token 
producer and consumer. I suppose that an STS can provide SAML2 tokens so 
the interoperability process nearly consists on a XML document 
conversion (WS-Trust/SAML protocol) and resignature (transitive trust 
ensured by the trusted third party). For the moment, I focused on authn 
requests/responses, considered that WS-Fed authn context limitation (in 
comparison to SAML) was not one and I did not solve any privacy concerns 
yet i.e. Ws-Fed pseudonyms provider / IdP nameID mgmt interop.
I think that in the next few days I will work on these issues and I will 
study if a prototype is feasable.
I take part to the FederID project 
http://federid.objectweb.org/xwiki/bin/view/Main/WebHome sponsorized by 
the French Research Agency. One of the software component we use is a C 
API, SAML2 conformant, called Lasso developped by a FederID member 
(Entrouvert). But I don't know WS-Fed API yet...

If anybody think these works could help him or be interesting for the 
Concordia community I would be pleased to help/contribute.

Best Regards,

Mikaël Ates
DIOM Laboratory - ISTASE School of Engineers
University of Saint-Etienne - FRANCE
mikael.ates at univ-st-etienne.fr
+33 4 77 43 50 34

Beach, Michael C wrote:
> In response to the questions for Mike B.:
>
> Both SP-initiated and IdP-initated flows are real in our production environment.  I don't have real metrics but I would guess it is somewhat balanced between the two.
>
> SAML/WS-Fed features we have in production today are basic SSO, SAML authentication assertions.  The only information passed is the user identifier.  In both incoming and outgoing scenarios the destination site maintains an "asserted" to "internal" identifier mapping.
>
> We are testing claims-enabled end points today and have defined use cases where various attributes/claims would accompany an authentication assertion including an indication of the underlying user authentication strength.  Documents I have seen point back to the 4 NIST authentication levels. 
>
>
> Mike Beach, CISSP
> Chief Security Designer
> Information Security
> The Boeing Company
> michael.c.beach at boeing.com
>
> -----Original Message-----
> From: Eve Maler [mailto:Eve.Maler at Sun.COM] 
> Sent: Thursday, January 10, 2008 10:30 AM
> To: community at projectconcordia.org
> Subject: [Concordia] Notes from 10 Jan 2008 Concordia call
>
> I'll put these notes up on the wiki shortly.  Please let me know if you have corrections.
>
> Attending:
>
> Scott Cantor (Shib)
> Ashish Jain (Ping)
> Mike Jones (Microsoft)
> Paul Madsen (NTT)
> Eve Maler (Sun)
> Sampo Kellomaki (Symlabs)
> Brett McDowell (LAP)
> Gaël Gourmelen (FT)
> George Fletcher (AOL)
> Jeff Hodges (Neustar)
> Uppili Srinivasan (Oracle)
>
>
> - Quick telecon time discussion
>
> The proposal is 1st and 3rd Tuesdays at 10-11am PT.  We'll doublecheck on the list, but all participants on this call seem fine with it.  
> We'll stick to the telecon number we used today; Brett says that's fine.
>
>
> - Quick ITU-T liaison discussion
>
> Abbie Barbir has offered to be a liaison, and we are okay with that!   
> We'd like to keep our liaison activities quite informal.
>
>
> - Quick roundup of interested RSA interop participants
>
> Everyone generally wants to see how the scenarios shake out and what system entity roles are involved before committing specifically to various flows, but all of the following confirmed active interest:
>
> * Eve confirms for Sun
> * Sampo confirms for Symlabs (participating in "all of the above"  
> flows!)
> * Mike confirms for MSFT (will participate with any WS-Fed and infocard parts, but they don't have a SAML kit today)
> * Scott confirms for Shib (SP parts for sure; not sure about other
> roles)
> * Ashish confirms for Ping
> * Lena confirmed by email for FuGen
>
>
> - Develop further detail on scenarios 1-2 and list any outstanding issues
>
> http://projectconcordia.org/index.php/RSA_IOP_Scenarios
>
> Paul notes that the email discussion in recent weeks went beyond what's on this page today.  Scenario 2 is the one of most interest, in which authentication mechanisms play an interesting part.  The question is how we choose to map such mechanisms into the infocard world.  Current consensus seems to be that SAML will define five URIs:  
> personal cards and the four permutations of managed cards.  We still have to define four corresponding claim types to express the latter four, in order to make the cards light up.  Mike confirms that it would be four claim types (vs. one claim with multiple values).  This is because you can't articulate values in a policy, so for the sake of being able to match policies, you need distinct claims.
>
> Regarding the request for authentication coming from a SAML SP, ultimately making its way to the STS: Mike confirms that MSFT has kernel code that a SAML token can come back from that.  Scott notes that it's up to the STS what gets produced, no matter how the request comes in.  Mike's product group wants to know from this community and the SAML community what example SAML tokens it would like to see coming from the MSFT code.
>
> Do we want to see an authentication context or attribute statements/ claim types?  At IIW the conclusion seemed to be to reuse authn context for responses because we shouldn't be inventing something new.  But because we have to use the claim type feature of the security policy framework, we need to be able to express the claim requests in attribute terms.  So, effectively, we need to map onto both representations.  (Paul observes that the GSA folks currently carry this sort of info in an attribute in responses.)
>
> MSFT is planning to put up an STS endpoint that produces tokens of the
> SAML2 flavor.  MSFT's WS-Fed implementation today supports SAML1.1 tokens and has internal code that supports SAML2 tokens.
>
> Scenarios 1 and 2 are both "SP-initiated" in SAML terms, as we have captured them so far.
>
> We think Boeing's basic scenario is a fine one to run with for now.
>
>
> - Scenario 11 (the "third interop scenario")
>
> This is the one where WS-Fed and SAML integrate.  Mike would like to see a description of how SAML expresses authentication contexts so he can discuss he implications with his WS-Fed team.  Does this scenario amount to SAML2/WS-Fed chaining (which is semantically similar to
> SAML2/SAML1.1 chaining)?  Hubert's previously blogged comparison matrix provides some basic info on this.  If we constrain ourselves to whatever is currently implemented, that limits the scope of the work we'd have to do on this scenario.
>
> Should we focus this scenario on IdP-initiated in order to spread around the different use cases a bit?  Scott is against this, since he feels SP-initiated is more "real-world".  WS-Fed and ADFS, according to Scott, support IdP-initiated flows.  Eve and Paul are inclined to include IdP-initiated somehow for its usefulness in shaking out interop issues.  Mike is disinclined because it may strain our resources.  Let's ask deployers for more input.
>
> How do people deal with chaining two technologies with differing features?  The easy answer (already demoed at Catalyst a couple of years ago) is to use only an intersection of the features, but there's obviously little interop trouble there.  More interesting is whether any deployers are "tunneling" features outside that intersection by using extension features of the more-capable technology.  We'd like to survey people on this.
>
>
> - AI roundup:
>
> - Scott to put some example SAML tokens onto the wiki for Mike, leveraging Paul's list of claim types needed.
> - Eve to ask Mike B. what specific SAML features they're using today and whether IdP-initiated flows are of interest.
> - Eve to ask deployers for input on whether, in existing chaining scenarios, they "tunnel" features.
> - (pending) Scott to flesh out the IdP discovery problem wiki page.
> - Scott to update the scenario detail on the wiki and refactor the wiki a bit.
>
>
> Eve Maler                                         +1 425 947 4522
> Principal Engineer                            eve.maler @ sun.com
> Business Alliances group                    Sun Microsystems, Inc.
> _______________________________________________
> Community mailing list
> Community at projectconcordia.org
> http://lists.projectconcordia.org/mailman/listinfo/community
>
> Participating in this discussion list does not grant any intellectual property rights or any commitment by the participants of the content discussed to any organization.
> _______________________________________________
> Community mailing list
> Community at projectconcordia.org
> http://lists.projectconcordia.org/mailman/listinfo/community
>
> Participating in this discussion list does not grant any intellectual property rights or any commitment by the participants of the content discussed to any organization.
>   