struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phase Web and Multimedia" <m...@phase.ws>
Subject RE: Security Solution
Date Mon, 01 Apr 2002 21:03:41 GMT
In reponse:

1) The use of this security solution is confined (at this point) to a
context in a host. Most of the time there is only one context per host.

2) It is a non-standard way of providing security checks. Many of the built
in role checking that is in struts/tiles and the programmatic security
checking would not be available. Although syntactically it would function
the same it would have no ties to the container managed security.

3) A servlet 2.3 compliant container with struts is necessary. It uses a
filter as the url guardian. I am sure the filter could be extracted and
tweaked to work in other situations other than struts.

4) There are a few options. There is container based security or you can
roll your own. Security has been (imho) a severly neglected area. As a
designer/developer I find it to be a pain in the butt that one is limited to
a single login page for all security constraints. This is the imposed
standard. Much of the way security is set up flys in the face of easy end
user interaction. Container managed security lacks the ability to login or
remain logged in. This is fairly absured imho. Others have developed front
end checks that work in conjunction with container managed security which
perform slight of hand logins. For example. if you want to use container
managed security you could initially redirect to a secure url that forwards
to an struts action or a servlet which first checks to see if a cookie
exists, then gathers u/p from the cookie and logs in and forwards to the
homepage. If a login is not found you can wait until someone hits a secure
url and forward them to the action login page. This smells like hackage.

5) If you want a list of competitive features read the other emails I have
posted to the list and read the servlet 2.3 spec. I am trying to get some
people thinking about intuitive security. I don't claim to have the answer
in my group of classes. I just claim to have a bit more flexibility. I don't
have any EJB or cross context fuctionality. Which other features do and of
course is of high value to many. So, I believe you can get a good idea for
what I have done by reading other posts with the same title as this article.

Let me know what you learn. If you have any contributions suggestions. I
would appreciate it. I don't claim to know anything much less everything :-)

Hope this helps,
Brandon Goodin
Phase Web and Multimedia
P (406) 862-2245
F (406) 862-0354
mail@phase.ws
http://www.phase.ws


-----Original Message-----
From: Neil Pitman [mailto:npitman@interlink.net]
Sent: Monday, April 01, 2002 1:31 PM
To: Struts Users Mailing List
Cc: Struts Developers List
Subject: Re: Security Solution


Hello Brandon,

This might be interesting to me, but then I'm a newbie so I'm not sure
whether I should be interested.

As an alternative to posting sources here, you could create a project on
SourceForge.net.  It would relieve this list of the specific traffic.

One aspect of documentation that I find particularly lacking is an
"appropriateness" section.  I expect it to be missing in commercial
documentation (because no one wants to lose a sale).  I have been
searching open source for the last few months.  I really have to dig
into each project to understand whether it is appropriate.

Could you provide:
1) indications for use
2) contra-indications against use
3) known complementary technologies (those it depends upon, those that
depend on it, those with a synergistic relationship)
4) known competative technologies (ones where I have to choose the one
feature set or another)
5) a comparative feature list (including versions of competitors).

Ok, it sounds like I want a month of the marketing department.  A line
or two would suffice.  Indeed, "unknown" would help - it would at least
tell me that I'm on my own.


Phase Web and Multimedia wrote:

> Greetings,
>
> I wanted to offer some code if anyone is interested. I have seen many
> discuss security on archives and wanted to offer an alternative to
container
> managed security.
>
> I spent some time weighing out whether to use container managed security
or
> not and came to the conclusion that I would use a filter for security.
There
> were several inflexibilities in the spec for container managed security. I
> wrote a security filter that functions very similar to container managed
> security. It has an xml config file that is used to protect urls. There
are
> a few differences in the config and how you define protected areas and
where
> you are directed.
>
> Basically there are three areas of greater flexibility.
>
> 1) you can define several security-constraint groups with different login
> pages.
> 2) you can login easily without having to hit a secure page first
> 3) you can set up an app specific security realm. (This can also be
> considered a limitation if you are maintaining cross context security, but
> you could easily tie into a larger security system if this is needed)
>
> Anyways, it is not the "standard" but it functions well and gives greater
> freedom. I found container managed security to be a greater "hack" job
when
> I wanted to accomplish my goals. If anybody is interested I can post it
for
> review. It is certainly not mature and the code is fit for my current
> situation with an eye to greater flexibility. I think that it could
provide
> a good starting point for a cross-container simple alternate solution to
the
> current container managed security.
>
> P.S. I have to improve the documentation :-)
>
> Thanks for your time,
> Brandon Goodin
> Phase Web and Multimedia
> P (406) 862-2245
> F (406) 862-0354
> mail@phase.ws
> http://www.phase.ws
>
>
> --
> To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>
>
>


--
Neil Pitman
npitman@interlink.net
+1.514.863.5465


--
To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message