Greetings Chuck, To my understanding, both. For authorization, it might not be a bad thing for the authorization scheme to reference such a "card" rather than keeping such records every which a place. It would be an interesting study to see what the consequences of such a referencing scheme would be. We could see a challenge such as privacy on the "card". Would Amazon play like another "PayPal"?
As far as authentication is concerned, there is are many assertion authentication movements. These seem simpler from the perspective that security is controlled at the proxy. Of course the big question is how much of this security is enough in the event of charge dispute? For sure, this will drive someone mental. But what is an evil scientist to do? Later, Daniel Beatty, ABD Computer Scientist China Lake Naval Air Warfare Center dan.bea...@me.com On Jan 29, 2010, at 10:21 AM, Chuck Hill wrote: > > On Jan 29, 2010, at 6:46 AM, Daniel Beatty 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. > > Authorization or authentication? > > >> 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. > > Don't tell. > > > Chuck > >> Daniel Beatty, ABD >> Computer Scientist >> China Lake Naval Air Warfare Center >> dan.bea...@me.com >> >> >> >> >> >> 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 (Webobjects-dev@lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com >>>> >>>> This email sent to webobje...@anazys.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: >>> http://lists.apple.com/mailman/options/webobjects-dev/danielbeatty%40mac.com >>> >>> This email sent to danielbea...@mac.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: >> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >> >> This email sent to ch...@global-village.net > > -- > Chuck Hill Senior Consultant / VP Development > > 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 arch...@mail-archive.com
