[wildfly-dev] Adding additional security domain to standalone.xml?

Eduardo Sant´Ana da Silva eduardo.santanadasilva at gmail.com
Wed Nov 4 05:43:13 EST 2015

Probably EAP 7.1 according to the latest info that I've got on elytron


Sorry by bother you guys, but what is the target distribution of the
elytron, replacing JAAS among the other authentication methods?

Darran Lofthouse·10:06 AM

By using names I could even see us providing organisations a way to
coordinate transitioning users passwords

David M. Lloyd·10:07 AM

or even having different passwords for different situations

Darran Lofthouse·10:12 AM

Elytron replaces JAAS as the integration point with the backing store of
identities, in addition to that is also provides a set of strong
authenitcation mechanisms for both HTTP and native access - other features
will be identity propagation of identities between processes and a general
imporovement of overall security context handling.

Here is the follow up issue for getCredentialSupport

Eduardo Sant'Ana da Silva·10:14 AM

I saw that it will be on EAP 7 as well, thanks for the information

David M. Lloyd·10:15 AM

EAP 7.1 probably, but yes

2015-11-04 7:57 GMT-02:00 arjan tijms <arjan.tijms at gmail.com>:

> Thanks a lot in advance!
> Any idea on the Elytron timeline btw? Is that post EAP 7 or earlier?
> Kind regards,
> Arjan Tijms
> On Wed, Nov 4, 2015 at 10:40 AM, Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>> I will have a look at what we can do, as we are transitioning to Elytron
>> long term we should be aiming to avoid all workarounds like this.
>> On 04/11/15 09:37, arjan tijms wrote:
>>> Hi,
>>> On Fri, Oct 30, 2015 at 10:19 AM, arjan tijms <arjan.tijms at gmail.com
>>> <mailto:arjan.tijms at gmail.com>> wrote:
>>>     I wonder if it would make sense to put the generic jaspic security
>>>     domain by default in standalone.xml. It's always the same anyway.
>>>     With the domain present in a stock WildFly it's much easier for
>>>     people to start with JASPIC on WildFly.
>>> Anyone has any thoughts on this?
>>> WildFly currently has one of the best JASPIC implementations out there,
>>> but this relatively tiny problem is a big hurdle for usability, and
>>> especially impedes using WildFly for JSR 375 demonstrations.
>>> Hope something can be done here.
>>> Kind regards,
>>> Arjan Tijms
>>>     It concerns this fragment:
>>>       <security-domain name="jaspitest" cache-type="default">
>>>          <authentication-jaspi>
>>>              <login-module-stack name="dummy">
>>>                  <login-module code="Dummy" flag="optional"/>
>>>              </login-module-stack>
>>>              <auth-module code="Dummy"/>
>>>          </authentication-jaspi>
>>>       </security-domain>
>>>     Kind regards,
>>>     Arjan Tijms
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151104/bc7fab64/attachment-0001.html 

More information about the wildfly-dev mailing list