Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of lightguard.jp@gmail.com
 designates 209.85.213.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGJtJfGKkwq00Y0o-crKv+kJ+YZ1dy9dv6A-dTY5V-xmK+T62A@mail.gmail.com>
References: 
 <CAF9TksNoLeM6JdVXUifS6FzP+OyxUpxZBcPXg4LrVMZwSc7c3g@mail.gmail.com>
 <1343342474.1574.YahooMailNeo@web28905.mail.ir2.yahoo.com>
 <CAN+FrnW6Z=TaUUCM0J-R-=+nj=1W6OiZHJY+y_7V1y4zp7xNtQ@mail.gmail.com>
 <5012A4FD.1050800@gmail.com>
 <CAGJtJfGAQA+C_D+nfNTRzQOtcqwQEXTKg2XPPcxAPUy_TQWFxw@mail.gmail.com>
 <CAF9TksN__6KiYgZMMjkmxiscvyWF+rU9oQaBC_EdvM7x_x=6bQ@mail.gmail.com>
 <1343428168.23451.YahooMailNeo@web28901.mail.ir2.yahoo.com>
 <CAF9TksNEzxOGoCVLV-eVrNY1hQecjGsV9jW9Whn4tRpjR1moEw@mail.gmail.com>
 <CAGJtJfGKkwq00Y0o-crKv+kJ+YZ1dy9dv6A-dTY5V-xmK+T62A@mail.gmail.com>
From: Jason Porter <lightguard.jp@gmail.com>
Date: Fri, 27 Jul 2012 17:01:55 -0600
Message-ID: 
 <CAF9TksOnDCKpQfC4hyGm_Y9LTZXTiq9HXfBH3LGzjnw4SKqN+g@mail.gmail.com>
Subject: Re: IDM impl feedback
To: deltaspike-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e89a8f23579d0cc73d04c5d7b422

--e89a8f23579d0cc73d04c5d7b422
Content-Type: text/plain; charset=UTF-8

That's fine, we can address this at a later time. I'd prefer to get v0.3
out the door sooner.

On Fri, Jul 27, 2012 at 4:54 PM, Gerhard Petracek <
gerhard.petracek@gmail.com> wrote:

> hi jason,
>
> i removed them as well (in the preview), because they don't work without
> org.apache.deltaspike.security.api.idm.User.
> since we agreed on a different/new goal, we can re-visit those parts for
> the upcoming module.
> (maybe we will re-add e.g. some of the events, but for now we don't know
> what we will need.)
>
> if we just revert back to what we had in v0.2, we wouldn't change a lot
> (and we have more or less the same).
>
> regards,
> gerhard
>
>
>
> 2012/7/28 Jason Porter <lightguard.jp@gmail.com>
>
> > You're thinking in v0.4 then? There's not a LOT of new stuff in v0.3 but
> we
> > have waited a while to release, we should probably get started soon on
> the
> > release.
> >
> > On Fri, Jul 27, 2012 at 4:29 PM, Mark Struberg <struberg@yahoo.de>
> wrote:
> >
> > > I'd rather have the mini-auth + some composite components + a small
> > > default login handling in a separate module.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: Jason Porter <lightguard.jp@gmail.com>
> > > > To: deltaspike-dev@incubator.apache.org
> > > > Cc:
> > > > Sent: Saturday, July 28, 2012 12:11 AM
> > > > Subject: Re: IDM impl feedback
> > > >
> > > >G erhard, you heard my thoughts on adding the authentication stuff
> back
> > > in.
> > > > I'd like to suggest doing this either for v0.3 or v0.4 if we don't
> add
> > > > it
> > > > in to v0.3.
> > > >
> > > > On Fri, Jul 27, 2012 at 3:01 PM, Gerhard Petracek <
> > > > gerhard.petracek@gmail.com> wrote:
> > > >
> > > >>  hi @ all,
> > > >>
> > > >>  since also everybody involved in the original implementation agreed
> > > with
> > > >>  4b, i've created a jira-ticket [1] for the first two steps.
> > > >>  please review the changes for step #1. if there are no objections,
> > i'll
> > > >>  push it to our repository in two days and i'll close the
> jira-tickets
> > > >>  related to those topics.
> > > >>
> > > >>  regards,
> > > >>  gerhard
> > > >>
> > > >>  [1] https://issues.apache.org/jira/browse/DELTASPIKE-249
> > > >>
> > > >>
> > > >>
> > > >>  2012/7/27 Marius Bogoevici <marius.bogoevici@gmail.com>
> > > >>
> > > >>  > 4b looks a good way to go for me as well.
> > > >>  >
> > > >>  >
> > > >>  > On 2012-07-27 9:44 AM, Cody Lerum wrote:
> > > >>  >
> > > >>  >> +1 4b
> > > >>  >> On Jul 26, 2012 4:41 PM, "Mark Struberg"
> > > > <struberg@yahoo.de> wrote:
> > > >>  >>
> > > >>  >>  Oki, here we go.
> > > >>  >>>
> > > >>  >>> We had a quick chat about where we basically stand today.
> > > >>  >>>
> > > >>  >>>
> > > >>  >>> This is not intended to be a a 'what shall be' but
> > > > more a 'what do we
> > > >>  >>> have' + 'what do we really need' email.
> > > >>  >>>
> > > >>  >>>
> > > >>  >>> 1.) What we have today:
> > > >>  >>> I've looked at the Security module and what I understand
> > > > it's pretty
> > > >>  >>> powerful and complex.
> > > >>  >>> There are aprox. 30++ Interfaces which are very flexible but
> > > > also very
> > > >>  >>> hard to get right. Having lots of flexibility also makes it
> > > > easy to do
> > > >>  >>> things wrong as user. E.g. IdentityManager which allows to
> > > > create
> > > >>  users.
> > > >>  >>> The RoleQuery and the whole Role management is pretty complete
> > > > from the
> > > >>  >>> API
> > > >>  >>> level but I've never seen it used in such detail in any
> > > > application
> > > >>  yet.
> > > >>  >>> Most times there is an additional mapping role -> rights.
> > > > And the right
> > > >>  >>> is
> > > >>  >>> what gets used in the application (e.g. in rendered= ).
> > > >>  >>>
> > > >>  >>> 2.) What is available in projects:
> > > >>  >>> In my last 10 projects we never had the choice to define our
> > > > own login
> > > >>  >>> logic. Some customers had radius, others authenticated against
> > > > SAP or
> > > >>  >>> kerberos. Then there are some LDAP and we even have a single
> > > > sign on
> > > >>  >>> based
> > > >>  >>> on Smalltalk. And there is absolutely no way to get rid of
> > > > those! Most
> > > >>  of
> > > >>  >>> the time you cannot even create your own users... Of course
> > > > there is
> > > >>  the
> > > >>  >>> need for a simple html based user login for _some_
> > > > applications. But
> > > >>  this
> > > >>  >>> is most times only needed for green-field projects. Whenever
> > > > you do
> > > >>  >>> projects for a bigger company you most likely will find some
> > > > well
> > > >>  >>> established SSO in place.
> > > >>  >>>
> > > >>  >>> 3.) what is needed in those projects:
> > > >>  >>> I did quite some integration already in the past and the only
> > > > thing
> > > >>  which
> > > >>  >>> we did really need was
> > > >>  >>>
> > > >>  >>>    3.a.) to express some interrest: "current user likes
> > > > to do actionX"
> > > >>  >>> This can be done via a @Secured interceptor, via @ViewConfig,
> > > > via
> > > >>  >>> @PageBean etc -> might get provided by DS.
> > > >>  >>>
> > > >>  >>>    3.b.) to evaluate the "is the current user allowed to
> > > > do actionX"
> > > >>  >>> Like with JAAS Voters this can be done via a simple Interface
> > > > which
> > > >>  >>> returns a boolean. This is really similar to what Seam2 had
> > > > and also
> > > >>  what
> > > >>  >>> CODI did.
> > > >>  >>> All the evaluation and binding to an existing authorisation
> > > > and
> > > >>  >>> authentication can be done in this
> > > > AccessVoter/checkPermission. -> we
> > > >>  >>> might
> > > >>  >>> provide the Interfaces in DS. The impl is _always_ up to the
> > > > user.
> > > >>  >>>
> > > >>  >>> 4.) what are our options:
> > > >>  >>>
> > > >>  >>>    4.a.) fully implement our own security manager. This will
> > > > surely
> > > >>  still
> > > >>  >>> take some time as this is a complex topic! Many of the
> > > > interfaces are
> > > >>  ok
> > > >>  >>> but there is not yet an impl behind it. My personal estimation
> > > > is that
> > > >>  we
> > > >>  >>> now hit the 15% line, and a few people already spent a good
> > > > amount of
> > > >>  >>> power
> > > >>  >>> for it. So this will not be finished for the next 5 months I
> > > > fear.
> > > >>  >>>
> > > >>  >>> 4.b) implement a simple Voter + @Secured and let the user deal
> > > > with the
> > > >>  >>> rest. In both Seam2 and CODI this turned out to not only be
> > > > extremely
> > > >>  >>> flexible, but it is also rather easy to integrate [1]. We
> > > > could also
> > > >>  >>> provide an additional module which contains a composite
> > > > component with
> > > >>  >>> login userId + pwd fields + a simple backend for it. But just
> > > > as a
> > > >>  small
> > > >>  >>> additional module which might optionally be used for easier
> > > > integration
> > > >>  >>> into JSF apps if there is not yet an existing SSO
> > > > implementation.
> > > >>  >>>
> > > >>  >>> LieGrue,
> > > >>  >>> strub
> > > >>  >>>
> > > >>  >>>
> > > >>  >>> [1]
> > > >>  >>> https://github.com/struberg/**lightweightEE/blob/master/gui/**
> > > >>  >>> src/main/java/de/jaxenter/**eesummit/caroline/gui/**
> > > >>  >>> security/AdminAccessVoter.**java#L36<
> > > >>
> > > >
> > >
> >
> https://github.com/struberg/lightweightEE/blob/master/gui/src/main/java/de/jaxenter/eesummit/caroline/gui/security/AdminAccessVoter.java#L36
> > > >>  >
> > > >>  >>>
> > > >>  >>>
> > > >>  >>> ----- Original Message -----
> > > >>  >>>
> > > >>  >>>> From: Jason Porter <lightguard.jp@gmail.com>
> > > >>  >>>> To: deltaspike-dev@incubator.**apache.org<
> > > >>  deltaspike-dev@incubator.apache.org>
> > > >>  >>>> Cc:
> > > >>  >>>> Sent: Thursday, July 26, 2012 9:03 PM
> > > >>  >>>> Subject: IDM impl feedback
> > > >>  >>>>
> > > >>  >>>> T he implementation that's in HEAD right now is
> > > > incomplete. There are
> > > >>  >>>> many
> > > >>  >>>> methods which are basic IDE generated stubs in multiple
> > > > classes. I'll
> > > >>  >>>>
> > > >>  >>> hold
> > > >>  >>>
> > > >>  >>>> off on any feedback until it's complete.
> > > >>  >>>>
> > > >>  >>>> --
> > > >>  >>>> Jason Porter
> > > >>  >>>> http://lightguard-jp.blogspot.**com <
> > > >>  http://lightguard-jp.blogspot.com>
> > > >>  >>>> http://twitter.com/**lightguardjp
> > > > <http://twitter.com/lightguardjp>
> > > >>  >>>>
> > > >>  >>>> Software Engineer
> > > >>  >>>> Open Source Advocate
> > > >>  >>>> Author of Seam Catch - Next Generation Java Exception
> > > > Handling
> > > >>  >>>>
> > > >>  >>>> PGP key id: 926CCFF5
> > > >>  >>>> PGP key available at: keyserver.net, pgp.mit.edu
> > > >>  >>>>
> > > >>  >>>>
> > > >>  >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Jason Porter
> > > > http://lightguard-jp.blogspot.com
> > > > http://twitter.com/lightguardjp
> > > >
> > > > Software Engineer
> > > > Open Source Advocate
> > > > Author of Seam Catch - Next Generation Java Exception Handling
> > > >
> > > > PGP key id: 926CCFF5
> > > > PGP key available at: keyserver.net, pgp.mit.edu
> > > >
> > >
> >
> >
> >
> > --
> > Jason Porter
> > http://lightguard-jp.blogspot.com
> > http://twitter.com/lightguardjp
> >
> > Software Engineer
> > Open Source Advocate
> > Author of Seam Catch - Next Generation Java Exception Handling
> >
> > PGP key id: 926CCFF5
> > PGP key available at: keyserver.net, pgp.mit.edu
> >
>


-- 
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu

--e89a8f23579d0cc73d04c5d7b422--