Skip to Content.
Sympa Menu

shibboleth-dev - Re: authentication authority

Subject: Shibboleth Developers

List archive

Re: authentication authority


Chronological Thread 
  • From: Tom Scavo <>
  • To:
  • Subject: Re: authentication authority
  • Date: Wed, 5 Oct 2005 11:06:03 -0400
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PUH2oatw+PDKGTK+snmSj6Jx1Wcb9VsjJ00Hz2KtEehSFu/Y1k7GqBzkcXjW/jZuaQZiingtLfYLXsRaUuF4T8Hssv8kGUw2NNU/kmA7dyGTli//hiZ+eiRdstmFSzgYDgoOtETdHzOyqZ8wbneyZq09duZUuLdZUyDuZ/CaIHY=

On 10/4/05, Scott Cantor
<>
wrote:
>
> Is your thought that the user would authenticate to
> the My-Proxy component using a SAML bearer assertion that it gets from
> interacting with a SAML SSO service?

Currently, MyProxy accepts username/password and validates this
credential against the local authN service (via PAM or SASL). So one
thought is to authenticate to MyProxy and then pass this
authentication context on to the IdP, receiving an authentication
assertion in return.

Here is a one possible scenario (by no means the only one we've considered):

PRECONDITIONS

+ A Shibboleth Identity Provider (IdP) is deployed in administrative
domain A. The IdP is integrated with a local authentication service
provided by A.
+ GridShib for Shibboleth is installed and configured on top of the
IdP. (In what follows, we will refer to this enhanced IdP as simply
"IdP".)
+ Globus Toolkit (GT) is deployed in administrative domain B.
+ GridShib for Globus Toolkit is installed and configured on top of
GT. (From now on, we will refer to this enhanced GT deployment as a
Grid Service Provider or simply "SP".)
+ MyProxy Server is deployed in administrative domain A. MyProxy
Server is integrated with the local authentication service (via PAM or
SASL).
+ A Grid User has an account with the local authentication service in
administrative domain A.
+ The IdP and SP each have been assigned a unique identifier called a
providerId.
+ The IdP and SP rely on the same metadata format and exchange this
metadata out-of-band.

OVERVIEW

This GridShib profile consists of eight (8) steps:

1) A MyProxy Client, on behalf of the Grid User, sends a MyProxy
Protocol request to the MyProxy Server. The Grid User's
authentication credentials (username/password) are included with the
request.
2) The MyProxy Server validates the authentication credentials against
the local authentication service. The MyProxy Server, on behalf of
the Grid User, issues an HTTP request against a custom IdP protocol
handler protected by basic auth. The request includes the
time-to-live (TTL) of the proxy certificate.
3) The IdP validates the username/password in the request and returns
a SAML authentication assertion to the MyProxy Server. The TTL of the
ShibHandle in the authentication assertion matches the TTL of the
proxy certificate.
4) The MyProxy Server inserts the entire authentication assertion into
a proxy certificate, signs the certificate, and returns it to the
MyProxy Client.
5) A Grid Client, on behalf of the Grid User, POSTs a SOAP request to
the SP, authenticating with the proxy credential.
6) The SP validates the authentication assertion in the proxy
certificate and POSTs a SAML SOAP message to the Attribute Authority
(AA) at the IdP. The SAML Subject in the authentication assertion
becomes the Subject of the AttributeQuery.
7) The AA returns an attribute assertion to the SP.
8) The SP performs the requested operation and returns a response to
the Grid Client.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page