Re: Single Sign-On
I’ve also deployed with shibboleth SSO at UCLA. By far, the harder part was configuring shibboleth. Tim UCLA GSE&IS > On Feb 23, 2018, at 11:25 AM, Chuck Hill wrote: > > And I've integrated these and it was pretty straightforward: > http://weblogin.org > https://www.shibboleth.net > > Chuck > > On 2018-02-23, 11:22 AM, "Webobjects-dev on behalf of Steve Peery" > spe...@me.com> wrote: > >I’m not sure what you have in mind, but the ERGoogleSignIn framework makes > it very easy to log into a WO site using a google account. > >Steve > > >> On Feb 23, 2018, at 2:10 PM, Robert Hanviriyapunt wrote: >> >> Any useful resources in integrating with SSO services in WebO? >> >> = Robert = >> ___ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com >> >> This email sent to spe...@me.com > > ___ >Do not post admin requests to the list. They will be ignored. >Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com > >This email sent to ch...@gevityinc.com > > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/lists%40thetimmy.com > > This email sent to li...@thetimmy.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Single Sign-On
And I've integrated these and it was pretty straightforward: http://weblogin.org https://www.shibboleth.net Chuck On 2018-02-23, 11:22 AM, "Webobjects-dev on behalf of Steve Peery" wrote: I’m not sure what you have in mind, but the ERGoogleSignIn framework makes it very easy to log into a WO site using a google account. Steve > On Feb 23, 2018, at 2:10 PM, Robert Hanviriyapunt wrote: > > Any useful resources in integrating with SSO services in WebO? > > = Robert = > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com > > This email sent to spe...@me.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com This email sent to ch...@gevityinc.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Single Sign-On
I’m not sure what you have in mind, but the ERGoogleSignIn framework makes it very easy to log into a WO site using a google account. Steve > On Feb 23, 2018, at 2:10 PM, Robert Hanviriyapunt wrote: > > Any useful resources in integrating with SSO services in WebO? > > = Robert = > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com > > This email sent to spe...@me.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Single Sign-On
Any useful resources in integrating with SSO services in WebO? = Robert = ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Single sign on in multiple WOApps / passing parameters between apps
This is one of the nastier issues that faces web developers, not just WebObjects, but all of the toolkits. There are some common approaches, but in general they all have some sort of security ramifications. The issue is that no matter what method you employ, in order to maintain context across disparate applications (and in some case the same application across a stateless cluster) requires that the context information be stored on the client, meaning a Cookie. Recognizing that a Cookie is intrinsically insecure, that means you have to deal with those ramifications as a part of the design. Now, that said, you could use the webserver itself to provide security, so that a single server hosting several apps could do single point authentication (which the web browser handles and then stores locally in it's own state management). Windows only shops use this model quite a bit to use built-in security against an enterprise Active Directory tree and they can do so more or less for free. There are problem with it. Depending upon the configuration, this approach can lock out non-Windows browsers, and can also lock out Windows machines that are not members of the AD tree. You can accomplish the same thing with prudent configuration of OpenDirectory and Apache. I wouldn't recommend it though. It makes deployment a bit of a PITA among other issues. Alright, so we've covered what I would I wouldn't do. How would I solve the problem? I've done it several ways, each have 'quirks', but the solution I found that scaled and worked the best used the databse auth just like you have now. Though I did the implementation in C# and ASP.NET, the principal design would work in the WO world as well. First, I created a single private web service that was used to validate a client context to an authorized session. When the user arrived at any of the shared applications, the application performed a check for a context id in the browsers cookies for the domain. If it wasn't found, displayed the login display. If it was found, but there was no corresponding local session, it hit the web service to validate the context id, and reconstitute a local session from the web service (refreshing the session expiration in the process). If the local session does exist, there is no need to display the login, but there is still a hit to the webserver to refresh the session in order to prevent it from expiring in the shared database of sessions. The weakness is of course that context. I've seen alot of web developers dump user id's, login & password combo's etc into the cookie. Every time I see this, I want to go crawl in a corner and cry. In the solution above, I stored a generated context id that was a server generated guid session id generated by the authentication web service. That guid would be commited the session database, with all of the relevant login information stored server side. The only thing stored at the browser/cookie level is an encrypted guid, that has a shelf life of the default session length (I elected to use 10 minute sessions, renewing them with each subsequent page view). A couple of notes though. For a reasonably low volume site, this is over engineered. Part of the reasons for the designs are that several of the applications in my case where load balanced across several servers and data centers. The reason I've continued to use this design is that it does scale relatively well, but retains a simple enough deployment model that new junior developers can easily integrate into it, knowing that with a couple of well documented calls to a common object, they get a fully constituted session with a well defined data set. I am just beginning to rebuild this in WO (or more specifically a single Java library) so that I can easily implement the same design in WO, only this time without the latency challenged web service and going direct to the DB from the Java library. Andy On Mar 6, 2007, at 2:30 PM, Pierre Bernard wrote: Hi! About a year ago I worked on a single sign-on system. Unfortunately, I didn't have the opportunity to complete it. I still have hopes to complete it. The basic principles are astonishingly simple: There is one application that handles authentication. When a user hits the entry page of another application, he gets a temporary redirection to the authentication application. An ID (e.g. base URL) of the originating application is passed in the URL. We also pass the ID of the freshly created WOSession. The user logs into the authentication application, creating an authenticated WO session. The user gets a standard cookie with the session's ID. Behind the scenes the authentication contacts the target application notifying the session of the user's credentials. Th
Re: Single sign on in multiple WOApps / passing parameters between apps
We've done extensive work with Single Sign On, integration of WebObjects applications into portals, etc. We have a JSR168 framework for portlets. We use that with back-end LDAP authentication to give a SSO like experience. We are working on a CAS solution to pass authentication tokens, but this is still in development. If you contact me offline I'd be happy to share it with you. - Ubique, Tom Termini -- e-mail: [EMAIL PROTECTED] direct dial: +353-1-440-1910 -- http://www.bluedog.ie Bluedog Ltd. Unit 3, 78, Furze Road, Sandyford Industrial Estate Sandyford Dublin 18 Ireland -- A Premier WebObjects solution provider: Knowledge worker applications via the internet: Services-oriented architecture, web services, portals, data encryption and extending legacy applications to web-enable organizations. On Mar 6, 2007, at 10:09 AM, Ken Tabb wrote: Hi folks, I think I must be missing something head-slappingly obvious. No. I have multiple WO apps, all running off the same user database, and for each app, the user authenticates against that user database before they're let into the app (i.e. the Main component has a conditional login form / page contents, depending on whether the user has already logged into that app). At the moment, when app1 sends a user to app2's URL, they are presented with another login form, which they then dutifully fill in even though it's using the same username/passwd combination they used for app1. First, I'd take a step back and look at the bigger picture. Does the University of Hertfordshire have an institutional authentication system (e.g. Kerberos, LDAP)? Do they have one for web apps? If so, that is the way to go. The web app ones that I have worked with (http://www.umich.edu/~umweb/software/cosign/, http:// www.stanford.edu/services/webauth/) are integrated into Apache and make integration with WebObjects dead simple (one line). Is it possible for app1 to take a logged in user to app2's default URL, and pass a parameter to the instance of app2 that's dealing with this request, along the lines of app2.setLoggedInUser(loggedInUser()); You can pass something on the URL or in a post or a cookie. But you will need to add a verification scheme to reduce the potential for hacking. Or, you can implement some sort of interprocess communication. Either way it is quite some work, especially compared to using a very secure solution (see above) and one line of code. The other route would be to have 1 monolithic "in house app" that does everything, but I'd be rebuilding that every couple of hours due to various parts being updated, so I'd rather keep things modular (several little apps) if possible. I agree, a monolithic app is the wrong direction to go in. Let me know if this needs clarifying, and thanks in advance for any help, I hope that helps. Chuck -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
Re: Single sign on in multiple WOApps / passing parameters between apps
Hi! About a year ago I worked on a single sign-on system. Unfortunately, I didn't have the opportunity to complete it. I still have hopes to complete it. The basic principles are astonishingly simple: There is one application that handles authentication. When a user hits the entry page of another application, he gets a temporary redirection to the authentication application. An ID (e.g. base URL) of the originating application is passed in the URL. We also pass the ID of the freshly created WOSession. The user logs into the authentication application, creating an authenticated WO session. The user gets a standard cookie with the session's ID. Behind the scenes the authentication contacts the target application notifying the session of the user's credentials. This can be hack proofed by accepting such communications only from localhost. Additionally the credentials could be signed. The page returned after login sets a standard cookie with the ID of the WOSession in the authentication application and then redirects back to the target application - right into the authenticated session. Now the user hits the entry page of another application. Again he is redirected to the authentication application. Now the cookie is read, the session restored and the login for is bypassed. The authentication immediately contacts the target application and then sends the redirection page. Best, Pierre Bernard Houdah Software s.à r.l. On Mar 6, 2007, at 7:09 PM, Ken Tabb wrote: Hi folks, I think I must be missing something head-slappingly obvious. I have multiple WO apps, all running off the same user database, and for each app, the user authenticates against that user database before they're let into the app (i.e. the Main component has a conditional login form / page contents, depending on whether the user has already logged into that app). At the moment, when app1 sends a user to app2's URL, they are presented with another login form, which they then dutifully fill in even though it's using the same username/passwd combination they used for app1. Is it possible for app1 to take a logged in user to app2's default URL, and pass a parameter to the instance of app2 that's dealing with this request, along the lines of app2.setLoggedInUser(loggedInUser()); The other route would be to have 1 monolithic "in house app" that does everything, but I'd be rebuilding that every couple of hours due to various parts being updated, so I'd rather keep things modular (several little apps) if possible. Let me know if this needs clarifying, and thanks in advance for any help, Ken - - - - - - - - - - Dr. Ken Tabb Mac & UNIX Developer - Health & Human Sciences Machine Vision & Neural Network researcher - School of Computer Science University of Hertfordshire, UK ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/webobjects- lists%40houdah.com This email sent to [EMAIL PROTECTED] - - - Houdah Software s. à r. l. http://www.houdah.com - Quality Mac OS X software - Premium WebObjects consulting ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
Re: Single sign on in multiple WOApps / passing parameters between apps
Hi Ken, On Mar 6, 2007, at 10:09 AM, Ken Tabb wrote: Hi folks, I think I must be missing something head-slappingly obvious. No. I have multiple WO apps, all running off the same user database, and for each app, the user authenticates against that user database before they're let into the app (i.e. the Main component has a conditional login form / page contents, depending on whether the user has already logged into that app). At the moment, when app1 sends a user to app2's URL, they are presented with another login form, which they then dutifully fill in even though it's using the same username/passwd combination they used for app1. First, I'd take a step back and look at the bigger picture. Does the University of Hertfordshire have an institutional authentication system (e.g. Kerberos, LDAP)? Do they have one for web apps? If so, that is the way to go. The web app ones that I have worked with (http://www.umich.edu/~umweb/software/cosign/, http:// www.stanford.edu/services/webauth/) are integrated into Apache and make integration with WebObjects dead simple (one line). Is it possible for app1 to take a logged in user to app2's default URL, and pass a parameter to the instance of app2 that's dealing with this request, along the lines of app2.setLoggedInUser(loggedInUser()); You can pass something on the URL or in a post or a cookie. But you will need to add a verification scheme to reduce the potential for hacking. Or, you can implement some sort of interprocess communication. Either way it is quite some work, especially compared to using a very secure solution (see above) and one line of code. The other route would be to have 1 monolithic "in house app" that does everything, but I'd be rebuilding that every couple of hours due to various parts being updated, so I'd rather keep things modular (several little apps) if possible. I agree, a monolithic app is the wrong direction to go in. Let me know if this needs clarifying, and thanks in advance for any help, I hope that helps. Chuck -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
Single sign on in multiple WOApps / passing parameters between apps
Hi folks, I think I must be missing something head-slappingly obvious. I have multiple WO apps, all running off the same user database, and for each app, the user authenticates against that user database before they're let into the app (i.e. the Main component has a conditional login form / page contents, depending on whether the user has already logged into that app). At the moment, when app1 sends a user to app2's URL, they are presented with another login form, which they then dutifully fill in even though it's using the same username/passwd combination they used for app1. Is it possible for app1 to take a logged in user to app2's default URL, and pass a parameter to the instance of app2 that's dealing with this request, along the lines of app2.setLoggedInUser(loggedInUser()); The other route would be to have 1 monolithic "in house app" that does everything, but I'd be rebuilding that every couple of hours due to various parts being updated, so I'd rather keep things modular (several little apps) if possible. Let me know if this needs clarifying, and thanks in advance for any help, Ken - - - - - - - - - - Dr. Ken Tabb Mac & UNIX Developer - Health & Human Sciences Machine Vision & Neural Network researcher - School of Computer Science University of Hertfordshire, UK ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
