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]
