New security sub-project: WildFly Elytron

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

New security sub-project: WildFly Elytron

David Lloyd-2
WildFly Elytron [1] is a new WildFly sub-project which will completely
replace the combination of PicketBox and JAAS as the WildFly client and
server security mechanism.

An "elytron" (ĕl´·ĭ·trŏn, plural "elytra") is the hard, protective
casing over a wing of certain flying insects (e.g. beetles).

Here is a high-level project summary:

WildFly Elytron does presently, or will, satisfy the following goals:

• Establish and clearly define terminology around WildFly's security
concepts
• Provide support for secure server-side authentication mechanisms (i.e.
eliminating the historical "send the password everywhere" style of
authentication and forwarding) supporting HTTP [2], SASL [3] (including
SASL+GSSAPI [4]), and TLS [5] connection types, as well as supporting
other authentication protocols in the future without change (such as
RADIUS [6], GSS [7], EAP [8])
• Provide a simple means to support multiple security associations per
security context (one per authentication system, including local and
remote application servers, remote databases, remote LDAP, etc.)
• Provide support for password credential types using the standard JCE
archetypal API structure (including but not limited to plain, UNIX
DES/MD5/SHA crypt types, bcrypt, mechanism-specific pre-hashed
passwords, etc.)
• Provide SPIs to support all of the above, such that consumers such as
Undertow, JBoss SASL, HornetQ etc. can use them directly with a minimum
of integration overhead
• Provide SPIs to support and maintain security contexts
• Integrate seamlessly with PicketLink IDM and Keycloak projects
• Provide SPIs to integrate with IDM systems (such as PicketLink) as
well as simple/local user stores (such as KeyStores or plain files, and
possibly also simple JDBC and/or LDAP backends as well)
• Provide SPIs to support name rewriting and realm selection based on
arbitrary, pluggable criteria
• Provide a Remoting-based connection-bound authentication service to
establish or forward authentication between systems
• Provide SPIs to allow all Remoting-based protocols to reuse/share
security contexts (EJB, JNDI, etc.)
• Integrate seamlessly with Kerberos authentication schemes for all
authentication mechanisms (including inbound and outbound identity
propagation for all currently supporting protocols)
• Provide improved integration with EE standards (JAAC and JASPIC)

The following are presently non- or anti-goals:

• Any provision to support JAAS Subject as a security context (due to
performance and correctness concerns)†
• Any provision to support JAAS LoginContext (due to tight integration
with Subject)
• Any provision to maintain API compatibility with PicketBox (this is
not presently an established requirement and thus would add undue
implementation complexity, if it is indeed even possible)
• Replicate Kerberos-style ticket-based credential forwarding (just use
Kerberos in this case)

† You may note that this is in contrast with a previous post to the AS 7
list [9] in which I advocated simply unifying on Subject.  Subsequent
research uncovered a number of performance and implementation weaknesses
in JAAS that have since convinced the security team that we should no
longer be relying on it.

Most of the discussion on this project happens in the #wildfly-dev+
(note the plus sign) channel on FreeNode IRC.  At some point in the
near-ish future I will hopefully also have some (open-source)
presentation materials about the architecture.

Questions and comments welcome; feel free to peruse the code and comment
in GitHub as well.

References/links:

[1] https://github.com/wildfly-security/wildfly-elytron
[2] http://tools.ietf.org/html/rfc2616
[3] http://tools.ietf.org/html/rfc4422
[4] http://tools.ietf.org/html/rfc4752
[5] http://tools.ietf.org/html/rfc5246
[6] http://tools.ietf.org/html/rfc2865 and
http://tools.ietf.org/html/rfc2866
[7] http://tools.ietf.org/html/rfc2743 and related
[8] http://tools.ietf.org/html/rfc3748
[9] http://lists.jboss.org/pipermail/jboss-as7-dev/2013-February/007730.html

--
- DML

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: New security sub-project: WildFly Elytron

Darran Lofthouse
In the interest of holding this in a central location I have created the
following article: -

   https://community.jboss.org/wiki/WildFlyElytron-ProjectSummary

Added the source and Jira links and also references for JBoss SASL which
although will evolve for WildFly Elytron will be remaining an
independent project.

Regards,
Darran Lofthouse.


On 04/06/14 03:21, David M. Lloyd wrote:

> • Establish and clearly define terminology around WildFly's security
> concepts
> • Provide support for secure server-side authentication mechanisms (i.e.
> eliminating the historical "send the password everywhere" style of
> authentication and forwarding) supporting HTTP [2], SASL [3] (including
> SASL+GSSAPI [4]), and TLS [5] connection types, as well as supporting
> other authentication protocols in the future without change (such as
> RADIUS [6], GSS [7], EAP [8])
> • Provide a simple means to support multiple security associations per
> security context (one per authentication system, including local and
> remote application servers, remote databases, remote LDAP, etc.)
> • Provide support for password credential types using the standard JCE
> archetypal API structure (including but not limited to plain, UNIX
> DES/MD5/SHA crypt types, bcrypt, mechanism-specific pre-hashed
> passwords, etc.)
> • Provide SPIs to support all of the above, such that consumers such as
> Undertow, JBoss SASL, HornetQ etc. can use them directly with a minimum
> of integration overhead
> • Provide SPIs to support and maintain security contexts
> • Integrate seamlessly with PicketLink IDM and Keycloak projects
> • Provide SPIs to integrate with IDM systems (such as PicketLink) as
> well as simple/local user stores (such as KeyStores or plain files, and
> possibly also simple JDBC and/or LDAP backends as well)
> • Provide SPIs to support name rewriting and realm selection based on
> arbitrary, pluggable criteria
> • Provide a Remoting-based connection-bound authentication service to
> establish or forward authentication between systems
> • Provide SPIs to allow all Remoting-based protocols to reuse/share
> security contexts (EJB, JNDI, etc.)
> • Integrate seamlessly with Kerberos authentication schemes for all
> authentication mechanisms (including inbound and outbound identity
> propagation for all currently supporting protocols)
> • Provide improved integration with EE standards (JAAC and JASPIC)
>
> The following are presently non- or anti-goals:
>
> • Any provision to support JAAS Subject as a security context (due to
> performance and correctness concerns)†
> • Any provision to support JAAS LoginContext (due to tight integration
> with Subject)
> • Any provision to maintain API compatibility with PicketBox (this is
> not presently an established requirement and thus would add undue
> implementation complexity, if it is indeed even possible)
> • Replicate Kerberos-style ticket-based credential forwarding (just use
> Kerberos in this case)
>
> † You may note that this is in contrast with a previous post to the AS 7
> list [9] in which I advocated simply unifying on Subject.  Subsequent
> research uncovered a number of performance and implementation weaknesses
> in JAAS that have since convinced the security team that we should no
> longer be relying on it.
>
> Most of the discussion on this project happens in the #wildfly-dev+
> (note the plus sign) channel on FreeNode IRC.  At some point in the
> near-ish future I will hopefully also have some (open-source)
> presentation materials about the architecture.
>
> Questions and comments welcome; feel free to peruse the code and comment
> in GitHub as well.
>
> References/links:
>
> [1]https://github.com/wildfly-security/wildfly-elytron
> [2]http://tools.ietf.org/html/rfc2616
> [3]http://tools.ietf.org/html/rfc4422
> [4]http://tools.ietf.org/html/rfc4752
> [5]http://tools.ietf.org/html/rfc5246
> [6]http://tools.ietf.org/html/rfc2865  and
> http://tools.ietf.org/html/rfc2866
> [7]http://tools.ietf.org/html/rfc2743  and related
> [8]http://tools.ietf.org/html/rfc3748
> [9]http://lists.jboss.org/pipermail/jboss-as7-dev/2013-February/007730.html
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: New security sub-project: WildFly Elytron

Radoslaw Rodak
In reply to this post by David Lloyd-2
> The following are presently non- or anti-goals:
>
> • Any provision to support JAAS Subject as a security context (due to
> performance and correctness concerns)†
> • Any provision to support JAAS LoginContext (due to tight integration
> with Subject)
> • Any provision to maintain API compatibility with PicketBox (this is
> not presently an established requirement and thus would add undue
> implementation complexity, if it is indeed even possible)
> • Replicate Kerberos-style ticket-based credential forwarding (just use
> Kerberos in this case)
>
> † You may note that this is in contrast with a previous post to the AS 7
> list [9] in which I advocated simply unifying on Subject.  Subsequent
> research uncovered a number of performance and implementation weaknesses
> in JAAS that have since convinced the security team that we should no
> longer be relying on it.


Is there any hope to have in Elytron a way to be able to integrate third part products supporting user identity propagation with JAAS like Corba, IBM MQ … with Wildfly?


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: New security sub-project: WildFly Elytron

David Lloyd-2
On 06/04/2014 02:40 PM, Radoslaw Rodak wrote:

>> The following are presently non- or anti-goals:
>>
>> • Any provision to support JAAS Subject as a security context (due to
>> performance and correctness concerns)†
>> • Any provision to support JAAS LoginContext (due to tight integration
>> with Subject)
>> • Any provision to maintain API compatibility with PicketBox (this is
>> not presently an established requirement and thus would add undue
>> implementation complexity, if it is indeed even possible)
>> • Replicate Kerberos-style ticket-based credential forwarding (just use
>> Kerberos in this case)
>>
>> † You may note that this is in contrast with a previous post to the AS 7
>> list [9] in which I advocated simply unifying on Subject.  Subsequent
>> research uncovered a number of performance and implementation weaknesses
>> in JAAS that have since convinced the security team that we should no
>> longer be relying on it.
>
>
> Is there any hope to have in Elytron a way to be able to integrate third part products supporting user identity propagation with JAAS like Corba, IBM MQ … with Wildfly?

Yes, however it may not be possible using one single integration
methodology.  Experience has shown that every vendor uses JAAS in
different ways, so we would have to approach each item on a case-by-case
basis.


--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: New security sub-project: WildFly Elytron

Darran Lofthouse
+1 Recently looking at how different JDBC driver vendors, and different
JDK vendors interpret the use of JAAS for Kerberos propagation there are
a lot of different interpretation of the same spec / APIs!!

On 04/06/14 21:34, David M. Lloyd wrote:

> On 06/04/2014 02:40 PM, Radoslaw Rodak wrote:
>>> The following are presently non- or anti-goals:
>>>
>>> • Any provision to support JAAS Subject as a security context (due to
>>> performance and correctness concerns)†
>>> • Any provision to support JAAS LoginContext (due to tight integration
>>> with Subject)
>>> • Any provision to maintain API compatibility with PicketBox (this is
>>> not presently an established requirement and thus would add undue
>>> implementation complexity, if it is indeed even possible)
>>> • Replicate Kerberos-style ticket-based credential forwarding (just use
>>> Kerberos in this case)
>>>
>>> † You may note that this is in contrast with a previous post to the AS 7
>>> list [9] in which I advocated simply unifying on Subject.  Subsequent
>>> research uncovered a number of performance and implementation weaknesses
>>> in JAAS that have since convinced the security team that we should no
>>> longer be relying on it.
>>
>>
>> Is there any hope to have in Elytron a way to be able to integrate third part products supporting user identity propagation with JAAS like Corba, IBM MQ … with Wildfly?
>
> Yes, however it may not be possible using one single integration
> methodology.  Experience has shown that every vendor uses JAAS in
> different ways, so we would have to approach each item on a case-by-case
> basis.
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: New security sub-project: WildFly Elytron

arjan.tijms
Hi,

On Thu, Jun 5, 2014 at 10:50 AM, Darran Lofthouse <[hidden email]> wrote:
+1 Recently looking at how different JDBC driver vendors, and different
JDK vendors interpret the use of JAAS for Kerberos propagation there are
a lot of different interpretation of the same spec / APIs!!

JAAS, and especially JAAS in Java EE, is not the universal standard you may think it is. Some parts are interpreted differently, but other parts are just not specified. How to store a username and roles in the "bag of principles" that the Subject is, is particularly notorious. I wrote a post about that subject (no pun) here: http://arjan-tijms.blogspot.com/2014/02/jaas-in-java-ee-is-not-universal.html

I wonder btw if any of the work done for this WildFly Elytron project (and previous work done for Picketbox/link) could possibly be used for feedback on how to improve the security APIs in Java EE itself. Has this ever been considered?

Kind regards,
Arjan

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: New security sub-project: WildFly Elytron

Darran Lofthouse


On 05/06/14 10:50, arjan tijms wrote:

> Hi,
>
> On Thu, Jun 5, 2014 at 10:50 AM, Darran Lofthouse
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     +1 Recently looking at how different JDBC driver vendors, and different
>     JDK vendors interpret the use of JAAS for Kerberos propagation there are
>     a lot of different interpretation of the same spec / APIs!!
>
>
> JAAS, and especially JAAS in Java EE, is not the universal standard you
> may think it is.

We have certainly come to that conclusion as well ;-)

My view on JAAS is that it is actually a client side API that pre-dated
J2EE, the J2EE specs left security decisions down to the vendors and as
at the time only simple security solutions were in demand (validate
plain text username and password) JAAS was quickly adopted as this was
something it could do.

It is then the demand for more complex solutions that have started to
show the limitations of how much can be achieved with it.

> Some parts are interpreted differently, but other parts
> are just not specified. How to store a username and roles in the "bag of
> principles" that the Subject is, is particularly notorious. I wrote a
> post about that subject (no pun) here:
> http://arjan-tijms.blogspot.com/2014/02/jaas-in-java-ee-is-not-universal.html
>
> I wonder btw if any of the work done for this WildFly Elytron project
> (and previous work done for Picketbox/link) could possibly be used for
> feedback on how to improve the security APIs in Java EE itself. Has this
> ever been considered?
>
> Kind regards,
> Arjan
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: New security sub-project: WildFly Elytron

Bill Burke
In reply to this post by David Lloyd-2
Is there a mail list for this?  Or are discussions here?

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: New security sub-project: WildFly Elytron

David Lloyd-2
On 06/11/2014 07:05 AM, Bill Burke wrote:
> Is there a mail list for this?  Or are discussions here?

Discussions are here.


--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: New security sub-project: WildFly Elytron

Darran Lofthouse
On 11/06/14 13:32, David M. Lloyd wrote:
> On 06/11/2014 07:05 AM, Bill Burke wrote:
>> Is there a mail list for this?  Or are discussions here?
>
> Discussions are here.

We took the decision that the kind of discussions we have need to be
visible to everyone that works on WildFly in one way another so starting
a new list and asking everyone to subscribe did not make sense.

>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev