7:17 a.m.
Hi devs,
how you doing?
I was checking out the security API proposed by Undertow and I've
identified that io.undertow.security.idm.IdentityManager receive an empty
credential as parameter in two of its methods. After taking a look into the
Java Docs and the exemple codes I figure out why.
As proposed in the original design, an IdentityManager should know which
kind of credential was created by the AuthenticationMechanism, cast it, and
then apply the desired identity match. It means that there's an existance
relation between both IdentityManager and AuthenticationMechanism.
Maybe, making Credential a generic parameter of IdentityManager it will
make IdentityManager more plugable. It also forces us the improve
SecurityContext with this new design.
A little sample copied from BasicAuthenticationMechanism.java[106~110] as
an exemple.
final IdentityManager<PasswordCredential> idm =
securityContext.getIdentityManagerFor( PasswordCredential.class );
final PasswordCredential credential = new PasswordCredential(password);
try {
final AuthenticationMechanismOutcome result;
Account account = idm.verify(userName, credential);
Let me know if this makes sense for Undertow needs!
Regards
5:14 a.m.
Hello Miere,
Thank you very much for your comments, at the moment we are actually
working on another project called wildfly-elytron - at a high level this
project is providing APIs and SPIs to allow different identity providers
to be plugged into WildFly for integration with authentication mechanisms.
We haven't started to touch Undertow yet but fairly soon we will need to
start reviewing the integration with Undertow which will be impacting on
the area you highlight here.
FYI negotiating supported credential types and strongly types
acquisition of them is central to Elytron.
Regards,
Darran Lofthouse.
On 29/07/14 13:17, Miere Teixeira wrote:
Hi devs,
how you doing?
I was checking out the security API proposed by Undertow and I've
identified that io.undertow.security.idm.IdentityManager receive an
empty credential as parameter in two of its methods. After taking a look
into the Java Docs and the exemple codes I figure out why.
As proposed in the original design, an IdentityManager should know which
kind of credential was created by the AuthenticationMechanism, cast it,
and then apply the desired identity match. It means that there's an
existance relation between both IdentityManager and AuthenticationMechanism.
Maybe, making Credential a generic parameter of IdentityManager it will
make IdentityManager more plugable. It also forces us the improve
SecurityContext with this new design.
A little sample copied from BasicAuthenticationMechanism.java[106~110]
as an exemple.
final IdentityManager<PasswordCredential> idm =
securityContext.getIdentityManagerFor( PasswordCredential.class );
final PasswordCredential credential = new PasswordCredential(password);
try {
final AuthenticationMechanismOutcome result;
Account account = idm.verify(userName, credential);
Let me know if this makes sense for Undertow needs!
Regards
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
6:56 a.m.
Thank you for your answer, Darran
Its nice to see the community moving forward so fast.
Let me know if you guys need help with something during this development.
I'm really interested in make Undertow run standalone for my customers
as a lightweight container. Authentication and Authorization is the only
missing gap here.
Regards,
Miere Teixeira
On Wed, Jul 30, 2014 at 7:14 AM, Darran Lofthouse <
darran.lofthouse(a)jboss.com> wrote:
Hello Miere,
Thank you very much for your comments, at the moment we are actually
working on another project called wildfly-elytron - at a high level this
project is providing APIs and SPIs to allow different identity providers
to be plugged into WildFly for integration with authentication mechanisms.
We haven't started to touch Undertow yet but fairly soon we will need to
start reviewing the integration with Undertow which will be impacting on
the area you highlight here.
FYI negotiating supported credential types and strongly types
acquisition of them is central to Elytron.
Regards,
Darran Lofthouse.
On 29/07/14 13:17, Miere Teixeira wrote:
> Hi devs,
> how you doing?
>
> I was checking out the security API proposed by Undertow and I've
> identified that io.undertow.security.idm.IdentityManager receive an
> empty credential as parameter in two of its methods. After taking a look
> into the Java Docs and the exemple codes I figure out why.
>
> As proposed in the original design, an IdentityManager should know which
> kind of credential was created by the AuthenticationMechanism, cast it,
> and then apply the desired identity match. It means that there's an
> existance relation between both IdentityManager and
AuthenticationMechanism.
>
> Maybe, making Credential a generic parameter of IdentityManager it will
> make IdentityManager more plugable. It also forces us the improve
> SecurityContext with this new design.
>
> A little sample copied from BasicAuthenticationMechanism.java[106~110]
> as an exemple.
>
> final IdentityManager<PasswordCredential> idm =
> securityContext.getIdentityManagerFor( PasswordCredential.class );
> final PasswordCredential credential = new
PasswordCredential(password);
> try {
> final AuthenticationMechanismOutcome result;
> Account account = idm.verify(userName, credential);
>
>
> Let me know if this makes sense for Undertow needs!
>
> Regards
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
3798
days inactive
3799
days old
2 comments
2 participants
participants (2)
-
Darran Lofthouse -
Miere Teixeira