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 pmuir@redhat.com designates
 209.132.183.28 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: IDM impl feedback
From: Pete Muir <pmuir@redhat.com>
In-Reply-To: <1343428168.23451.YahooMailNeo@web28901.mail.ir2.yahoo.com>
Date: Mon, 30 Jul 2012 11:25:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3ECE495C-B637-4FD7-8A75-105D48ADA33F@redhat.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>
To: deltaspike-dev@incubator.apache.org, Mark Struberg <struberg@yahoo.de>

I would like us to have this bit in, whether it's in a separate module, =
or core, that is fine by me.

On 27 Jul 2012, at 23:29, Mark Struberg wrote:

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