Skip to Content.
Sympa Menu

wg-pic - Re: [wg-pic] SAML use cases

Subject: Presence and IntComm WG

List archive

Re: [wg-pic] SAML use cases


Chronological Thread 
  • From: Tom Scavo <>
  • To:
  • Subject: Re: [wg-pic] SAML use cases
  • Date: Wed, 28 Oct 2009 19:28:30 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=uSAtKUissSCZ8xORDV80AoRNwNURvqFb/eHnnqmVoBTi2vODVSrNkybenZQ4NTND8f RLFt5uVevo/a2QO+fbas4Ks+zKcL0Jvf2OC6w4tlw8rN/8u68aoZf+ifk65a7qTIrJRS u7q5q288lkPiT3lqFRYjBud+KYTZr4xMGMf0U=

On Wed, Oct 28, 2009 at 4:36 PM, Peter Saint-Andre
<>
wrote:
>
> I might misunderstand what you mean by "protect this client with a
> Shibboleth Service Provider". I assumed you meant "require HTTP
> authentication or some other security mechanism to access the web
> client" but perhaps you mean something more sophisticated.

Let's forget about Shibboleth for the moment (since it tends to
confuse matters). The primary SAML use case is called SAML Web Browser
SSO. A SAML implementation (such as Shibboleth) knows how to do this
one thing (maybe others) very well. There are three actors in SAML Web
Browser SSO: the Identity Provider (a SAML producer), the Service
Provider (a SAML consumer), and a browser user. The latter transmits a
SAML assertion from the Identity Provider to the Service Provider
(details omitted). At a minimum, the assertion contains an
authentication statement. It may also contain an attribute statement
(used for access control). The Service Provider validates and parses
the assertion, and exposes the authentication context and attributes
to the protected application in some way, typically via HTTP headers
or server environment variables. The application uses this security
context for access control.

So I'd like to apply SAML Web Browser SSO in the case of a
browser-based group chat client. Has anyone done this before? (I'm
sure the answer is yes, we just need to find that person :)

>> And how do these clients authenticate themselves today?
>
> A client authenticates to its local server using its most preferred SASL
> mechanism from among the mechanisms offered by the local server.

Okay, I'll have to read up on SASL.

> Once it
> is on the network, right now it can access any resource that is not
> protected using primitive mechanisms like members-only chatrooms (where
> the list of members is manually configured by a room admin). We'd like
> to move beyond primitive mechanisms to things like role-based authorization.

Do you mean groups? Seems chat rooms are more akin to groups than roles...

Tom



Archive powered by MHonArc 2.6.16.

Top of Page