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

[Eduardo Sant´Ana da Silva]

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


>>>>>>>>>>>

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
https://issues.jboss.org/browse/ELY-299

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