I guess I have to look at Open SSO. From what time I did spend looking at Shib it didn't appear that any other frameworks would really be necessary.
Tim Worman UCLA GSE&IS On Feb 5, 2010, at 9:46 AM, Joe Little wrote: > Sadly I doubt I'd be able to build out a framework by August nor get > the necessary funding to attend WOWODC, but perhaps the following > event? Then again, Tim might be further along. I will start a project > come Sept 1 that will involve OpenSSO for use with Shibboleth for > Stanford that is not WO related, but I'll then be retrofitting most of > my WO projects to use that effort shortly afterwards. I think 2011 is > a safe target date (sadly) for anything from me. > > On Thu, Feb 4, 2010 at 4:02 PM, David Avendasora > <[email protected]> wrote: >> Now this sounds like a great WOWODC talk, especially by someone that has >> just implemented it! >> >> Dave >> >> On Jan 30, 2010, at 3:09 PM, Tim Worman wrote: >> >>> I'll be implementing shib here for at least one of my solutions in the very >>> near future. UCLA has migrated to it for all web authentication. I'd >>> definitely be interested to see what others have done with it. I'm actually >>> really looking forward to getting it done. It should definitely simplify a >>> lot of the "log in" process as far as my app is concerned. >>> >>> Tim Worman >>> UCLA GSE&IS >>> >>> On Jan 30, 2010, at 9:19 AM, Joe Little wrote: >>> >>>> I've been wanting to get my but off the ground and build out a WO >>>> howto on integrating with Shib. OpenSSO might make it easier, but the >>>> end result is still just getting a REMOTE_USER back that is asserted >>>> to be ok. Authorization levels won't be know, but most store that >>>> in-app (internal) or reference indirectly via LDAP or the methods >>>> noted above. >>>> >>>> On Fri, Jan 29, 2010 at 6:46 AM, Daniel Beatty <[email protected]> >>>> wrote: >>>>> Greetings Xavier, Mike, Cheong, and the Practical guys, >>>>> There are two features emerging that kind of like for this idea. One is >>>>> the CardDAV notion and second is this "assertion authentication" pattern >>>>> that has been implemented by Mobile Access Service, OpenSSO, and >>>>> Shibboleth. A link to the CardDAV reference, even if kept semi-private, >>>>> would be sufficient to have a unique reference to any user to be had. >>>>> Since both Apple and Amazon seem to be making such a standard available, >>>>> then it makes sense for authorization. >>>>> >>>>> If the Java OpenSSO (https://opensso.dev.java.net/) libraries can use the >>>>> assertions found in Shibboleth and Mobile Access environments, then this >>>>> would be a most useful for a wide spread and deployed WO app. >>>>> >>>>> But, Chuck may already have me on the certified list. Certified for >>>>> what, don't ask. >>>>> >>>>> Later, >>>>> >>>>> >>>>> Daniel Beatty, ABD >>>>> Computer Scientist >>>>> China Lake Naval Air Warfare Center >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Jan 29, 2010, at 4:35 AM, Xavier Destombes wrote: >>>>> >>>>>> Hello Cheong, >>>>>> >>>>>> Portability isn't a requirement for us, we just need to ensure we're >>>>>> using "standard" like if we use an Open Directory it's not a big deal, >>>>>> we will eventually only have to redo our read/write method to the ldap, >>>>>> but the attributes will be correct. >>>>>> We also have more and more related services, some come directly from OS >>>>>> X Server and some from our apps so being tied to the OS isn't an issue. >>>>>> >>>>>> What you explained also tells me I won't have to deal with security that >>>>>> much if I "forward" this to the ldap;) >>>>>> >>>>>> I'll probably have to dig a little bit more on this to understand how >>>>>> security will be handled for exemple in the following case: >>>>>> -someone trying to log to another user: if the ldap banish it for like >>>>>> 15mn after the 3rd attempt, I have to make sure the ldap get the correct >>>>>> originated IP and not the one from the core web app >>>>>> >>>>>> I've got quite a bunch of things to clarify before actually do it... >>>>>> >>>>>> Thanks for your inputs, >>>>>> >>>>>> Xavier >>>>>> >>>>>> >>>>>> >>>>>>> Coincidentally, I have completed a small framework on this same request >>>>>>> from customer. It is a pure java framework since it is aimed to be >>>>>>> portable to any application e.g. Broadvision, WO. Quite similar that >>>>>>> it creates new user password, authenticates user/password and returned >>>>>>> error messages. It also has the user capabilities on the access module >>>>>>> level. I used "Sha-1", and I thought it should be good enough for hash >>>>>>> algo. Is it secured enough? Otherwise, I could change to DES/3DES/ >>>>>>> MD4/5 etc. >>>>>>> Just 2c. >>>>>>> >>>>>>>>>> I've got multiple web applications that share some common users. >>>>>>>>>> I was thinking about creating a core user application to provide >>>>>>>>>> the authentication service. Basically I'd like my "client" >>>>>>>>>> applications to forward the login and password to this core user >>>>>>>>>> app and get either "succeed" or "fail" (maybe a broader range of >>>>>>>>>> fail messages). >>>>>>>>>> I don't really need the entire user to be stored directly in the >>>>>>>>>> "client" apps, but I would sometimes need some attributes from the >>>>>>>>>> user object. >>>>>>>>>> >>>>>>>>>> My though was: >>>>>>>>>> -to create a framework to store an abstract class for the user >>>>>>>>>> -to extend this class within the core user app (basically just make >>>>>>>>>> them non-abstract) >>>>>>>>>> -to use the abstract class in the client apps (and eventually make >>>>>>>>>> only a couple attributes non-abstract at that level) >>>>>>>>>> >>>>>>>>>> That way I could make sure my object is really the same throughout >>>>>>>>>> the apps, at least they share a commun set of attributes. >>>>>>>>>> A client app could request a login for a user and store only a >>>>>>>>>> subset of the user. >>>>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>> Webobjects-dev mailing list ([email protected]) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com >>>>>>> >>>>>>> This email sent to [email protected] >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Do not post admin requests to the list. They will be ignored. >>>>>> Webobjects-dev mailing list ([email protected]) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> http://lists.apple.com/mailman/options/webobjects-dev/danielbeatty%40mac.com >>>>>> >>>>>> This email sent to [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list ([email protected]) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> http://lists.apple.com/mailman/options/webobjects-dev/jmlittle%40gmail.com >>>>> >>>>> This email sent to [email protected] >>>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/lists%40thetimmy.com >>>> >>>> This email sent to [email protected] >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com >>> >>> This email sent to [email protected] >>> >>> >> >> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
