Skip to Content.
Sympa Menu

wg-pic - SAML use cases

Subject: Presence and IntComm WG

List archive

SAML use cases


Chronological Thread 
  • From: Tom Scavo <>
  • To: PIC WG <>
  • Subject: SAML use cases
  • Date: Wed, 28 Oct 2009 16:01:40 -0400
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=bwuIQFUyEYOmf2XuKEoZPOYd6CCqRNSH9I0GBWFpEbtALugTrvAJrRgZ07Izi2BvHP o5ymUVIVGLmcvxI5fgc0F2DQitHb0hR+zDQvw+dec4jvQ1ACxTVd6kcz3b2AE6t1RM1q 6yrpeBpYU+n5jIrUJwyiZNJkqKzT6pikKmrg0=

On the last call, I was asked to describe the use of SAML in
conjunction with X.509. Before I go off ranting and raving about
something that may turn out to be totally irrelevant for this group,
let me see if I understand the basic requirements I thought I heard on
the call. You're looking for a way to do back-channel
(server-to-server) access control, that is, an XMPP server calls out
to another XMPP server for an access control decision (or attributes
that can be used to make an access control decision). Am I even
halfway close to the truth? :-)

Close or not, consider this alternative use case (which for some
reason is the one I think I want to solve): Suppose I had a
browser-based group chat client. (I assume such things exist.) Now
protect this client with a Shibboleth Service Provider (or any
implementation of a SAML Service Provider) and map the supplied group
membership attribute(s) to the corresponding chat room(s).

The latter seems fairly straightforward compared to the former, so
this is where I think I need to start. Why is it thought that the
former is the problem we want to solve?

Thanks in advance,
Tom



Archive powered by MHonArc 2.6.16.

Top of Page