Mm

----- Message d'origine -----
De : cas-request
Envoyé : 04/10/2007 18:00
À : [email protected]
Objet : cas Digest, Vol 53, Issue 9



Send cas mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://tp.its.yale.edu/mailman/listinfo/cas
or, via email, send a message with subject or body 'help' to
        [EMAIL PROTECTED]

You can reach the person managing the list at
        [EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cas digest..."


Today's Topics:

   1. Re: ACEGI, CAS and stateless clients (Scott Battaglia)
   2. Re: SAML 2.0 (Google Accounts Integration) (Angel Q)


----------------------------------------------------------------------

Message: 1
Date: Thu, 4 Oct 2007 09:53:49 -0400
From: "Scott Battaglia" <[EMAIL PROTECTED]>
Subject: Re: ACEGI, CAS and stateless clients
To: "Yale CAS mailing list" <[email protected]>
Message-ID:
        <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"

Eric,

We used to include a sample web service that demonstrated this.  Turns out
that xFire didn't like Credentials being an interface so we were ending up
writing specific interfaces for each Credentials type we wanted to support.
Since we couldn't make it completely generic we didn't want to confuse
people.  However, if you can figure out how to make it generic, we always
like contributions :-)

Thanks!
-Scott

On 10/3/07, Eric Miles <[EMAIL PROTECTED]> wrote:
>
> Scott,
>
> Thanks, this is sort of the answer I figured was coming (from looking at
> the documentation) but was waiting for someone with a little more
> knowledge to confirm it :)
>
> I'm surprised that this requirement has not come up before.  My company
> (if we choose to go with CAS for our SSO solution) will absolutely be
> looking at this in the future.  Maybe it's something we can provide back
> to the project?
>
> Eric
>
> Scott Battaglia wrote:
> > Eric,
> >
> > If you wish to use CAS as both a Single Sign on Server and an
> > authentication mechanism, you'll want to expose the CAS Service Layer as
> > a web service (how you want to do that is your choice).  Then systems
> > can contact CAS with the user's credentials and receive a service ticket
> > for them.
> >
> > -Scott
> >
> > On 10/2/07, *Eric Miles*
> > <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >     The desire for this particular client goes beyond single
> sign-on.  Our
> >     desire is for a central source of authentication (which is a
> by-product
> >     of SSO).  We do not want to have to configure numerous applications
> >     with
> >     the same information to support authentication, be it against LDAP,
> DB
> >     mechanism, etc...
> >
> >     These particular clients are Blackberry clients that communicate to
> a
> >     series of web services.  This is currently done via WS-Security with
> >     UsernameToken.  These clients are authenticated against some Acegi
> >     Security code we've written, configured with Spring (it might be via
> >     LDAP, custom Daos, etc).
> >
> >     We've taken CAS and dropped in our Acegi Security code.  Now SSO
> >     enabled
> >     applications use CAS for authentication purposes.  If this
> configuration
> >     for authentication changes, we have to change it in CAS, the web
> service
> >     layer, some other application, etc, etc.
> >
> >     Not only do I desire SSO, I also desire a central source for
> >     authentication.  I do not want to have to configure numerous
> >     applications with LDAP and or Dao authentication schemes.  I'd like
> to
> >     do it in one place and I was hoping CAS would provide that.
> >
> >     Does that make any sense?
> >
> >     Thanks again for the help.
> >     Eric
> >
> >     Bill Bailey wrote:
> >      > Eric,
> >      >
> >      > Are your applications desktop (thick) client applications?
> >      >
> >      > Single sign-on requires that after you authenticate successfully
> >     to one
> >      > application, you remember some key information that proves to
> >     other apps
> >      > that you have already been authenticated. In the case of CAS, the
> >     ticket
> >      > granting cookie that is stored in the browser serves that
> purpose.
> >      >
> >      > In the absence of a browser (i.e. a common platform through which
> all
> >      > the applications are accessed), it isn't clear to me where this
> key
> >      > information would be 'remembered'. Each application that is
> >     subsequently
> >      > launched will have no idea that some other application already
> >      > authenticated the user and will have no choice but to ask for
> >      > credentials again.
> >      >
> >      > In this case, where is the single sign-on?
> >      >
> >      > Again, maybe I'm totally missing the point, but a more complete
> >     example
> >      > of how you see a typical flow going from the user's perspective
> would
> >      > help.
> >      >
> >      > Bill
> >      >
> >      > -----Original Message-----
> >      > From: [EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>
> >     [mailto:[EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>]
> >      > On Behalf Of Eric Miles
> >      > Sent: Tuesday, October 02, 2007 1:53 PM
> >      > To: [email protected]
> >     <mailto:[email protected]>
> >      > Subject: Re: ACEGI, CAS and stateless clients
> >      >
> >      > Scott,
> >      >
> >      > Thanks for the information.  I've looked at the protocol and it
> >     seems as
> >      >
> >      > though you are still required to login through CAS's web page,
> >     something
> >      >
> >      > my clients do not have the ability to do.  Is there a way to
> >      > programmatically authenticate?  The credential acceptor behavior
> >     will
> >      > not work as the login ticket must have a generated (webflow id)
> >     and the
> >      > credential requestor behavior redirects the user to a login
> screen.
> >      > Technically, I'd like to provide the user/password in some way,
> >     shape,
> >      > or form, without requiring the user to have to browse to a CAS
> >     webpage.
> >      >
> >      > Am I offbase in my assumptions?  Is what I desire unachievable
> >     with CAS
> >      > currently?
> >      >
> >      > Thanks so much,
> >      > Eric
> >      >
> >      > Scott Battaglia wrote:
> >      >> Eric,
> >      >>
> >      >> Take a look at:
> >      >>
> >     http://www.ja-sig.org/products/cas/overview/proxy_auth/index.html
> >     <http://www.ja-sig.org/products/cas/overview/proxy_auth/index.html>
> >      >>
> >      >> It details Proxy Authentication and there are links to the
> actual
> >      >> protocol.  If you plan on using Acegi, take a look at
> >      >> www.acegisecurity.org <http://www.acegisecurity.org>
> >     <http://www.acegisecurity.org>.  There's a guide
> >      >
> >      >> that details how to CASify an application.  There should also be
> >      >> information on passing a CAS ticket via BASIC Auth.
> >      >>
> >      >> -Scott
> >      >>
> >      >> On 9/27/07, *Eric Miles*
> >      >> <[EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>
> >      >> <mailto: [EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>>> wrote:
> >      >>
> >      >>     I too am about to go down this road at looking to use CAS
> for
> >      >>     authentication for stateless clients (web services).  I have
> CAS
> >      >>     integrated into a web application, so I have knowledge of
> >     how that
> >      > works
> >      >>     and how it all ties togeter.  However, I'm unsure as to
> where to
> >      > begin
> >      >>     to look at using CAS for stateless clients.  Do you have any
> >      > suggestions
> >      >>     about where to look for documents and/or examples for this?
> >      >>
> >      >>     Thanks so much.
> >      >>
> >      >>     Eric
> >      >>
> >      >>
> >      >>     Bill Bailey wrote:
> >      >>      > Never mind. I found my answer. It was right in front of
> >     me all
> >      >>     along. It
> >      >>      > is explicitly provided in the configuration of the
> >      > ServiceProperties
> >      >>      > used to configure the ProxyTicketValidator.
> >      >>      >
> >      >>      >
> >      >>      > Bill
> >      >>      >
> >      >>      >
> >      >>      >
> >      >>      >
> >      >>      >
> >      >>      >
> >      >>
> >      >
> >
> ------------------------------------------------------------------------
> >
> >      >>      >
> >      >>      > *From:*
> >     [EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>
> >      >>     <mailto:[EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>>
> >      >>      >
> >     [mailto:[EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>
> >      >>     <mailto:[EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>>] *On
> >     Behalf
> >      >>      > Of *Bill Bailey
> >      >>      > *Sent:* Monday, August 06, 2007 11:21 AM
> >      >>      > *To:* Yale CAS mailing list
> >      >>      > *Subject:* ACEGI, CAS and stateless clients
> >      >>      >
> >      >>      >
> >      >>      >
> >      >>      > Hi,
> >      >>      >
> >      >>      >
> >      >>      >
> >      >>      > I am using Spring-WS, ACEGI, and CAS together to add
> >     security
> >      > to
> >      >>     my web
> >      >>      > services. I have gotten as far as generating a proxy
> >     ticket for
> >      >>     the web
> >      >>      > services to use, but I cannot determine what service I
> >     should
> >      > say the
> >      >>      > ticket is for because I can't figure out what ACEGI
> passes as
> >      > the
> >      >>     name
> >      >>      > of the service when it validates the ticket.
> >      >>      >
> >      >>      >
> >      >>      >
> >      >>      > Can anyone tell me how ACEGI forms the service name when
> it
> >      > calls
> >      >>      > proxyValidate? I have tried the name of the URL that
> >     represents
> >      >>     the web
> >      >>      > service endpoint, but it doesn't seem to work. And I
> >     can't find
> >      >>     the URL
> >      >>      > logged anywhere in the CAS log files so I can tell what
> >     service
> >      > I
> >      >>     should
> >      >>      > be using.
> >      >>      >
> >      >>      >
> >      >>      >
> >      >>      > Thanks.
> >      >>      >
> >      >>      >
> >      >>      > Bill
> >      >>      >
> >      >>      >
> >      >>      >
> >      >>
> >      >>     _______________________________________________
> >      >>     Yale CAS mailing list
> >      >>     [email protected]
> >     <mailto:[email protected]>
> >      >>     <mailto:[email protected]
> >     <mailto:[email protected]>>
> >      >>     http://tp.its.yale.edu/mailman/listinfo/cas
> >     <http://tp.its.yale.edu/mailman/listinfo/cas>
> >      >>
> >      >>
> >      >>
> >      >>
> >      >> --
> >      >> -Scott Battaglia
> >      >>
> >      >> LinkedIn: http://www.linkedin.com/in/scottbattaglia
> >     <http://www.linkedin.com/in/scottbattaglia>
> >      >> <http://www.linkedin.com/in/scottbattaglia>
> >      >>
> >      >
> >      > _______________________________________________
> >      > Yale CAS mailing list
> >      > [email protected]
> >     <mailto:[email protected]>
> >      > http://tp.its.yale.edu/mailman/listinfo/cas
> >
> >     _______________________________________________
> >     Yale CAS mailing list
> >     [email protected]
> >     <mailto:[email protected]>
> >     http://tp.its.yale.edu/mailman/listinfo/cas
> >
> >
> >
> >
> > --
> > -Scott Battaglia
> >
> > LinkedIn: http://www.linkedin.com/in/scottbattaglia
> >
>
> _______________________________________________
> Yale CAS mailing list
> [email protected]
> http://tp.its.yale.edu/mailman/listinfo/cas
>



-- 
-Scott Battaglia

LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://tp.its.yale.edu/pipermail/cas/attachments/20071004/b84fe3b9/attachment-0001.html
 

------------------------------

Message: 2
Date: Thu, 4 Oct 2007 08:18:45 -0700 (PDT)
From: Angel Q <[EMAIL PROTECTED]>
Subject: Re: SAML 2.0 (Google Accounts Integration)
To: Yale CAS mailing list <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"

Hi Scott,

I realize my previous email did not have enough info on my status, I will try 
again:

I gave been through the SAML 2.0 (Google Accounts Integration) and works 
aparently fine, but what I need now is to store the google account data and 
generate the session in google apps.

cas-servlet.xml and the google account are configured but I feel I am missing 
the info on where to generate the google ticket (session).

Also, what about "/cas/services/manage.html"? is this necessary?  what is it 
for exactly?  I had some trouble until I found out  it was 
"/cas/services/j_acegi_cas_security_check" what I had to have as the 1st entry 
LOL

Thanks a lot!!

Angel 


----- Original Message ----
From: Scott Battaglia <[EMAIL PROTECTED]>
To: Yale CAS mailing list <[email protected]>
Sent: Thursday, October 4, 2007 3:28:35 PM
Subject: Re: SAML 2.0 (Google Accounts Integration)

We have documentation here:

http://www.ja-sig.org/wiki/display/CASUM/SAML+2.0+%28Google+Accounts+Integration%29


Hope that helps.
-Scott

On 10/4/07, Angel Q <[EMAIL PROTECTED]> wrote:
Hello there,

I have done everything I have found on the docs to connect my CAS server to 
Google Apps, but I dont know how to proceed from this point.


Status:
CAS server setup and fed from LDAP
CAS Services Management Open and wntries created. (where can I get more info on 
this area)
Login to my site works, but, how can I define the values for Google, or where 
can I add what so the google apps session is started?


http://www.ja-sig.org/wiki/display/CASUM/Home


Thanks a lot,


Angel
PS: Please make it for dummies :)




      Yahoo! oneSearch: Finally,  mobile search 
that gives answers, not web links. 



_______________________________________________
Yale CAS mailing list
[email protected]

http://tp.its.yale.edu/mailman/listinfo/cas





-- 
-Scott Battaglia

LinkedIn: http://www.linkedin.com/in/scottbattaglia







      
____________________________________________________________________________________
Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, 
and more!
http://tv.yahoo.com/collections/3658 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://tp.its.yale.edu/pipermail/cas/attachments/20071004/479e8d8b/attachment-0001.html
 

------------------------------

_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas


End of cas Digest, Vol 53, Issue 9
**********************************
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas

Reply via email to