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/archive%40mail-archive.com This email sent to [email protected]
