Re: Accessing Service on Behalf of the User--supported in OpenId?

2008-08-15 Thread James Henstridge
2008/8/15 Scott Battaglia [EMAIL PROTECTED]:
 Hi everyone,

 I'm the lead developer on the JASIG Central Authentication Service, one of
 the SSO servers that a number of higher education institutions use.
 Traditionally, CAS has used its own de-facto standard protocol (CAS1 and
 CAS2) which are similar in concept to much of OpenId 1.1.  We have a couple
 of additional things built in (and you guys have some stuff we don't as
 optional specifications).

 As part of the evolution of the CAS SSO server, we've been including support
 for additional protocols beyond CAS.  To date, we can support CAS1, CAS2,
 SAML 1.1, part of SAML2 and are an OpenID 1.1 provider (the dumb model).

 We're looking to expand CAS into the realm of federation.  We've been
 looking at SAML2 which while extremely powerful can also be very complex and
 goes against the concepts we've introduced in CAS1 and CAS2 (i.e. simplicity
 of protocol). OpenId gives us a much warmer, fuzzy feeling :-), so we're
 doing some initial analysis of utilizing OpenId 2 as our method for
 federation (in the nice boxes we've drawn on our white board it seems to
 work well).

 I just have a few questions for a comparison of the OpenId protocol vs. the
 CAS protocol that we're obvious to me. The main question is:

 1. Do you guys support accessing a service on behalf of a user.  In CAS we
 call this proxying on behalf of the user.  But essentially, if you're say, a
 portal, and you need to access the grades, you would retrieve a CAS proxy
 ticket and give it to the grades service which would resolve that to the
 user as well as the chain of where it came from.

There are a few models that can be used for this:

1. The user goes to the grades service and requests that their data
get transferred to the OpenID provider via the attribute exchange
protocol.  When they go to the portal site, the portal can request the
data from the OP, again using attribute exchange.

Of course, in this model there is no direct contact between the portal
and grades service in this model, so the portal would need some way of
verifying that the data it got was correct.  Digital signatures are
probably the answer here, but there is no standard for this yet (there
was a proposal for this a while back though).

2. Use OAuth.  The portal acquires an access token to the grades
service.  This involves sending the user to the grades service to
authenticate (which might be done using OpenID).  The portal can then
use the access token to request the data directly from the grades

 Some of the other stuff is more related to local SSO needs than the actual
 protocol, but I'll ask anyway:
 1. Do you support a method of determining whether someone has authenticated
 already (in CAS we call it gateway)?  For us it relies on the fact that you
 always point to one CAS server, which obviously doesn't need to be true in
 the case of OpenId.However, in the scenario where you know there is only
 one authenticating server, is this possible?

If you are implementing a closed single sign-on system, you can do the
1. Make the OpenID provider implement an identifier select endpoint.
2. Make the OpenID provider automatically authenticate users who have
already authenticated (perhaps just to known sites).
3. For the relying party sites, if the user is unknown (according to
local session cookie), begin an OpenID authentication request to the
identifier select endpoint.  The result will include the user's

If you are designing an open system (user can use whatever provider
they want), I don't think there is an answer to this (which provider
are you asking whether the user is authenticated to?).

 2. Similar to above, we support a concept of opting-out and forcing
 re-authentication.  So an application that contains SSNs may basically tell
 the authentication server, I don't care if they've authenticated already, do
 it again.

The PAPE extension would be appropriate here:

A relying party site can ask the OP to reauthenticate the user if they
were previously authenticated more than N seconds ago (N can be zero).
 Of course, there is nothing to prevent an OP from lying about
reauthenticating the user.  If that matters to you, then only accept
OpenID providers you trust.

 The last question:  We don't actually do this in CAS yet, but we've seen it
 and a few people have asked for it.  Is there a way to pass information
 along to say something like I need them to authenticate via
 username/password, or cert, or LOA2 or higher?

Again, the PAPE extension should handle this.

 Thanks for any answers you guys can provide.  We'll be continuing to do
 research into how OpenId2 fits into the CAS world, but I wanted to see if I
 could get some of these basic protocol comparison questions out of the way.

specs mailing list

OWASP Certification

2008-08-15 Thread McGovern, James F (HTSC, IT)
Figured I would ask a somewhat offtopic question to see if anyone has
thoughts. I am currently project leader for OWASP Certification Project
which has on its roadmap, certification questions around identity.

What types of things about OpenID in specific or identity in general
should be covered? Post any thoughts you have here:

This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.

specs mailing list