Re: WO Authentication
Re: WO Authentication
- Subject: Re: WO Authentication
- From: Robert Walker <email@hidden>
- Date: Wed, 5 Mar 2003 21:00:55 -0500
Does anyone here have experience with the JavaWOSecurityExample
framework?
I have it working quite well in development mode on Mac OS X, however,
I am having difficulty getting it going on our Win2k deployment server.
Just something I have to work through.
My point it that it does exactly what you guys need.
If you're just getting started with WebObjects this may seem a bit
overwhelming. I know I felt a bit overwhelmed at first, but once I
understood what what going on it really wasn't that bad.
The really cool thing about it is that you don't really have to decide
ahead of time which pages you want to secure and which ones you don't.
All you have to do is edit a property list file to allow or deny access
to your components and direct actions. I really hope this stuff is
rolled into the standard WebObjects frameworks someday, if that's even
possible.
If you are interested please feel free to contact me either through
this mailing list or contact me directly.
Following is an excerpt from the API Users Guide:
------------------------
JavaWOSecurityExample provides classes for:
Credential Gathering
HTML page, HTTP challenge panel, and digital certificate are supported.
To customize the login panel look, you should subclass the class
SPLoginPanel. To support HTTP challenge, you have to use a web server,
a web server interface, and associated interface adaptor that will pass
the "authorization" header along to your app. Netscape web servers
don't unless you use the NSAPI interface. Digital certificate login
requires a web server that is configured to provide HTTPS and challenge
for a client certificate.
Resource protection
You can specify a default access posture for you app: default to deny
access for example. And then provide a list of resources to exempt from
the selected posture. You can assume a posture and exemption list for
both pages and actions. For example you can say you want to allow all
direct actions except these X, and deny all pages except these Y.
SSL Privacy and Protection
You can specify a posture and exemptions with regard to SSL access for
your resources. For example you can elect to deny access to these X
pages unless they are over SSL but allow access to everything else
whether over SSL or not. You can also specify that either an access
denied page be displayed when https is required on a page accessed with
http, or redirect to the page over https automatically when needed.
On-demand login
This features means that before resources are granted access, the app
will prompt for login, and then take the user directly to the resource
requested. On-demand login works for:
Page generation via ComponentActions with unexpired session IDs for
HTML page, HTTP panel, and certificate login
Page generation via DirectActions with unexpired, expired, or absent
session IDs for HTML page, HTTP panel, and certificate login
DirectAction invocation for HTTP panel and certificate login. And now
also works with an HTML page login. Instead of going directly to the
destination page, the login page used to take the user to the default
page. But now it does a redirect to the original direct action that
raised the login, thus reinvoking the action. In order for this to work
properly, you must carefully follow the hidden field usage and naming
used in any custom SPLoginPage you may decide to use. [In DirectAction
protection, remember, we are saying that we want the "fooAction" denied
unless the user is logged in. But we don't know where the "fooAction"
will go since you have to be done with the action before it generates a
page.]
Sessionless login attempts
Sometimes it is desirable to deny the creation of session unless the
user is logged in. This means your app needs to generate a login
request w/o creating a session and process a login attempt and not
create a session unless the user is authorized ok. Another benefit of
the sessionless login page is it can be accessed at anytime without
complaining about a session timeout.
Login prompting on session timeout
Instead of showing the default session expire page, you can go directly
to the login response which can be either HTML page or HTTP challenge
panel or implicit certificate authorization.
Session hijacking protection
You can enable a feature that prevents someone from accessing someone
else's session merely by acquiring their session ID. Once you have a
user's session ID, you no longer need to authenticate from a remote
console. Session hijacking works by emitting a cookie that is not
visible in a browser's location field or on the rendered source of
pages. The app checks on every request before rendering any page or
invoking any action that the hijacking cookie is present and correct.
The cookie is a value unique to the session, never repeating, and
optionally encrypted.
On Tuesday, March 4, 2003, at 09:17 AM,
email@hidden wrote:
> Have you checked out chapter 7 of Professional WebObjects 5 from Wrox.
> There
> is an sample solution for validating users and enforcing access on
> later
> pages.
> Adrian Williams wrote:
>> Thanks for the feedback Ray,
>>
>> I experimented with this too, and it works fine for performing the
>> initial
>> validation of the user,
>> but now I'm interested in the best way to secure each and every
>> component >in
> the application, so
>> that any 'bookmarked' pages will redirect to the login page if this
>> session
>> hasn't already been
>> validated.
>>
>> I was considering extending the WOComponent class as a
>> 'SecureComponent'
>> class (or similar) and
>> having the constructor check the Session object for a 'validated'
>> instance
>> variable or maybe check
>> for a client cookie, etc. etc....
>>
>> Obviously there's a million ways you could do this, but I was
>> wondering
>> whether there is an
>> accepted 'best-practice' way of doing it... Just trying to avoid
>> re-inventing the wheel really
>> (especially if, as a beginner with WO, I do it in a duff way!)...
>>
>> All pointers would be very welcome...
>>
>> Thanks again
>> Adrian Williams
>>
>>
>>> Adrian,
>>>
>>> I find myself to be in a place very similar to yours. I have just
>> finished the tutorials and am
>>> working on my first "real" project.
>>>
>>> The way I approached the situation was to create a database table of
>> users (was also relevant
>>> as was presenting data appropriate to the user, so needed a login).
>>> I
>> then created the Main
>>> page with 2 fields (login & password) and then had a fetch for
>>> records
>> matching those entries.
>>>
>>> If there was one matching record (hopefully there will never be more
>>> >than
> one) then the user
>>> was validated.
>>>
>>> I also altered it at a later stage where it did the fetch to match
>>> the
>> login id, and then did a
>>> comparison to see if the password matched. This was just so I could
>>> give
>> a different error
>>> message dependant on whether the login was bad, or the password.
>>>
>>> I don't know if there are more secure methods, but there is one
>>> option.
>>>
>>> Ray.
>>>
--
Think Different,
Robert Walker
http://www.robertwalker1.com
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.