Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gerhard.petracek@gmail.com
 designates 209.85.160.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D336F43A-1CDF-4F3D-AF57-B3D8CD83BB8E@redhat.com>
References: 
 <CAF9TksNoLeM6JdVXUifS6FzP+OyxUpxZBcPXg4LrVMZwSc7c3g@mail.gmail.com>
 <1343342474.1574.YahooMailNeo@web28905.mail.ir2.yahoo.com>
 <5011CE5B.6040300@redhat.com>
 <D336F43A-1CDF-4F3D-AF57-B3D8CD83BB8E@redhat.com>
From: Gerhard Petracek <gerhard.petracek@gmail.com>
Date: Fri, 27 Jul 2012 01:36:06 +0200
Message-ID: 
 <CAGJtJfFu_Bim3sUMFqt4_p+z2xh67YYjqXCDTY7u23EwR2LBxA@mail.gmail.com>
Subject: Re: IDM impl feedback
To: deltaspike-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e89a8ff243c167976404c5c41024

--e89a8ff243c167976404c5c41024
Content-Type: text/plain; charset=ISO-8859-1

since 4b is a slightly improved version of what we have in codi (and it's
enough imo): +1 for it

regards,
gerhard


2012/7/27 Pete Muir <pmuir@redhat.com>

> Having looked at what we had in 0.2 (
> https://github.com/apache/incubator-deltaspike/tree/5e4a7eb4de01004206f24ae22b9850e643bffe54/deltaspike/modules/security/api/src/main/java/org/apache/deltaspike/security/apiis the link into the tag :-), I think this would be a good point to stay
> with. The authorization API looks good, and the basic Authentication API
> that is there is very useful for those on some projects. It was very
> popular in Seam 2 (to which it is similar) I know :-)
>
> On 27 Jul 2012, at 00:10, Shane Bryzak wrote:
>
> > I had a quick chat with Pete and Jason and they brought me up to speed.
>  After much consideration I think the best way to proceed would be 4.b),
> with the more complex features such as IDM and permission management
> handled external to DS.
> >
> > On 27/07/12 08:41, Mark Struberg 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
> >>
> >>
> >> ----- Original Message -----
> >>> From: Jason Porter <lightguard.jp@gmail.com>
> >>> To: 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://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
> >>>
> >
> >
>
>

--e89a8ff243c167976404c5c41024--