Re: Core services design patern
Re: Core services design patern
- Subject: Re: Core services design patern
- From: Chuck Hill <email@hidden>
- Date: Fri, 29 Jan 2010 10:21:05 -0800
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
email@hidden
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden