The RESTful API is NOT designed for that type of behavior, nor is it supposed to be used for that. The goal of the RESTful API is to allow for service-to-service non-human interaction without handing passwords over to other services (one could use certificates to do a similar thing).
At Rutgers, our APIs (we actually have SOAP and not REST at the moment) are configured such that you can't even send the username/password for a user via that programmable API. Cheers, Scott On Mon, Mar 15, 2010 at 12:45 PM, William G. Thompson, Jr. <[email protected] > wrote: > On Mon, Mar 15, 2010 at 12:14 PM, Scott M. Holodak > <[email protected]> wrote: > >> Sure you could. In the local install (start menu) launch, the app > >> could just request the user's credentials and authN directly against > >> CAS. > > > > The only problem with authenticating in the client app is that the > > client app can't [easily] initiate an SSO session and pass proxy tickets > > back to web browsers. > > True, but I was assuming that in the local launch, SSO was out of the > question. The .NET Client could just use the CAS Server REST API to > authN the user and not worry about Tickets at all. > > http://www.ja-sig.org/wiki/display/CASUM/RESTful+API > > Bill > > > > It would have to listen for a pgtIOU from the CAS > > server in order to be able to generate proxy tickets. On the other > > hand, if all users start out on the web and end up in the app, the > > browser that they started out in should have SSO between apps. Your > > best bet might be to install shortcuts on the desktops that point to the > > ClickOnce deploy page. > > > > I say "can't easily" above because it _could_ be done, but is more > > complicated. > > > > Let's rule out the possibility where the ClickOnce app would act as an > > SSL-enabled web server which, aside from being nearly impossible > > infrastructure-wise (business policy, firewalls, SSL cert/DNS, NAT > > routing/UPnP issues), is very difficult to accomplish in a ClickOnce > > app. Listening for HTTP traffic in a ClickOnce would require admin > > rights and UAC considerations--ClickOnce+UAC is tricky. The app needs > > to be signed with a commercial code-signing cert or a code-signing cert > > trusted by all possible clients. > > > > The only other viable option that I can think of is to setup a helper > > web server to act as the PgtUrl on your client's behalf and takes care > > of the PgtIou-to-Pgt ticket resolution during the validation. Your > > client app would then need to check-in with the server a shortly after > > validating the ticket to get the PGT back. I'm not familiar enough with > > the protocol to know whether this is possible/allowed. > > > > -Scott > > > >> -----Original Message----- > >> From: William G. Thompson, Jr. [mailto:[email protected]] > >> Sent: Monday, March 15, 2010 11:07 AM > >> To: [email protected] > >> Subject: Re: [cas-user] Does CAS offer SSO between web applications > > AND > >> a .NET fat client deployed with click once ? > >> > >> On Mon, Mar 15, 2010 at 10:27 AM, Scott M. Holodak > >> <[email protected]> wrote: > >> > Hi Damien, > >> > > >> > I'm not 100% sure about this, but I think the problem you will run > >> into has to do with what the cookie store is. When you open up > > Firefox > >> and login to a CASified application, Firefox stores a cookie which it > >> presents to the CAS server when another web application needs to > >> authenticate. However, if you open up Internet Explorer and connect > > to > >> that second web application, the cookie doesn't exist from IE's > >> perspective and CAS forces you to re-authenticate. This is the same > >> kind of problem that you're going to run into. > >> > > >> > It might be possible to work around this, but I'm not sure whether > >> this would be considered a best practice from a security perspective. > >> If the ClickOnce deploy page is CASified (i.e., the user needed to > >> login to your web app before they could click the link that launches > >> the application), you could theoretically tweak that page to get a > >> proxy ticket and pass it into the ClickOnce application via > > querystring > >> (see: http://msdn.microsoft.com/en-us/library/ms172242.aspx). Your > >> application would then be able to parse the proxy ticket out and > > verify > >> it using HttpWebRequest or WebClient in the application code. Keep in > >> mind though that your users would always need to launch the > > application > >> from the web application in order to get the proxy ticket. In other > >> words, you couldn't configure the ClickOnce app to allow local > >> installations (Start Menu). It would always need to be launched > >> through the CASified web app. > >> > >> > >> Bill > >> > >> > >> > > >> > -ScottH > >> > > >> > > >> >> -----Original Message----- > >> >> From: Damien Azambourg [mailto:[email protected]] > >> >> Sent: Monday, March 15, 2010 4:56 AM > >> >> To: [email protected] > >> >> Subject: [cas-user] Does CAS offer SSO between web applications AND > >> a > >> >> .NET fat client deployed with click once ? > >> >> > >> >> Hello, > >> >> > >> >> We would like to know if CAS is able to offer a SSO between, in one > >> >> hand, web applications (J2EE, .NET) and, in the other end, .NET fat > >> >> client deployed with Click.Once of Microsoft and launched from a > >> >> browser. > >> >> > >> >> Currently, the .NET fat client shows a form in the GUI of the fat > >> >> client and communicates a login/pwd to IIS. > >> >> > >> >> In fact, we don't know how to do SSO between theses two worlds > > (thin > >> >> clients and fat clients) and we are hoping CAS can do it. > >> >> > >> >> Thanks and Regards, > >> >> > >> >> Damien > >> >> -- > >> >> You are currently subscribed to [email protected] as: > >> >> [email protected] > >> >> To unsubscribe, change settings or access archives, see > >> http://www.ja- > >> >> sig.org/wiki/display/JSG/cas-user > >> > > >> > -- > >> > You are currently subscribed to [email protected] as: > >> [email protected] > >> > To unsubscribe, change settings or access archives, see > >> http://www.ja-sig.org/wiki/display/JSG/cas-user > >> > >> -- > >> You are currently subscribed to [email protected] as: > >> [email protected] > >> To unsubscribe, change settings or access archives, see http://www.ja- > >> sig.org/wiki/display/JSG/cas-user > > > > > > -- > > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
