March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6366) Tutorial for the basic installation and setup of WildFly

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6366?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-6366: ----------------------------------- Could you guys "convert" this into blog post / news for wildfly.org page https://github.com/wildfly/wildfly.org or maybe create wiki page on WildFly wiki https://developer.jboss.org/en/wildfly/dev/content?filterID=contentstatus... (select Write an article) > Tutorial for the basic installation and setup of WildFly > -------------------------------------------------------- > > Key: WFLY-6366 > URL: https://issues.jboss.org/browse/WFLY-6366 > Project: WildFly > Issue Type: Feature Request > Reporter: Shishir Subramanyam > Assignee: Jason Greene > Priority: Trivial > Attachments: WildFly10_Tutorial1.pdf, WildFly10_Tutorial2.pdf > > > We created a tutorial for the basic installation and setup of WildFly (for windows and linux) at university and wanted to share it with the admins -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6366) Tutorial for the basic installation and setup of WildFly

by Shishir Subramanyam (JIRA)

Shishir Subramanyam created WFLY-6366: ----------------------------------------- Summary: Tutorial for the basic installation and setup of WildFly Key: WFLY-6366 URL: https://issues.jboss.org/browse/WFLY-6366 Project: WildFly Issue Type: Feature Request Reporter: Shishir Subramanyam Assignee: Jason Greene Priority: Trivial Attachments: WildFly10_Tutorial1.pdf, WildFly10_Tutorial2.pdf We created a tutorial for the basic installation and setup of WildFly (for windows and linux) at university and wanted to share it with the admins -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1394) default maxPermgen is added when jvm isn't configured

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1394?page=com.atlassian.jira.plugi... ] Ken Wills edited comment on WFCORE-1394 at 3/14/16 12:39 PM: ------------------------------------------------------------- Martin, is this OK to close? Never, mind I just needed to mark resolved. was (Author: luck3y): Martin, is this OK to close? > default maxPermgen is added when jvm isn't configured > ------------------------------------------------------ > > Key: WFCORE-1394 > URL: https://issues.jboss.org/browse/WFCORE-1394 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Martin Simka > Assignee: Ken Wills > Fix For: 2.1.0.CR2 > > > Default maxPermgen size is added when {{jvm}} element isn't specified in domain.xml/host.xml and warning is logged. > {code:xml} > <server-group name="main-server-group" profile="default"> >  > <socket-binding-group ref="standard-sockets"/> > </server-group> > {code} > {noformat} > WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: null > {noformat} > It happens because default is defined in [JvmElement.java#L76|https://github.com/wildfly/wildfly-core/blob/master/h...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1394) default maxPermgen is added when jvm isn't configured

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1394?page=com.atlassian.jira.plugi... ] Ken Wills reassigned WFCORE-1394: --------------------------------- Assignee: Ken Wills (was: Martin Simka) > default maxPermgen is added when jvm isn't configured > ------------------------------------------------------ > > Key: WFCORE-1394 > URL: https://issues.jboss.org/browse/WFCORE-1394 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Martin Simka > Assignee: Ken Wills > Fix For: 2.1.0.CR2 > > > Default maxPermgen size is added when {{jvm}} element isn't specified in domain.xml/host.xml and warning is logged. > {code:xml} > <server-group name="main-server-group" profile="default"> >  > <socket-binding-group ref="standard-sockets"/> > </server-group> > {code} > {noformat} > WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: null > {noformat} > It happens because default is defined in [JvmElement.java#L76|https://github.com/wildfly/wildfly-core/blob/master/h...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-19) Add KeyCloak based realm implementation.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-19?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse commented on ELY-19: ------------------------------------- I think we still need to explore the question "Can KeyCloak expose a security realm that can be used with other authentication mechanisms?" i.e. at it's core KeyCloak has a database of users with credentials so in a server that contains the KeyCloak subsystem other options could also be a possibility. This may then become the second option for username/password auth for things like CLI access. > Add KeyCloak based realm implementation. > ---------------------------------------- > > Key: ELY-19 > URL: https://issues.jboss.org/browse/ELY-19 > Project: WildFly Elytron > Issue Type: Sub-task > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Fix For: 1.1.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1394) default maxPermgen is added when jvm isn't configured

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1394?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1394: ------------------------------------- Fix Version/s: 2.1.0.CR2 (was: 3.0.0.Alpha1) > default maxPermgen is added when jvm isn't configured > ------------------------------------------------------ > > Key: WFCORE-1394 > URL: https://issues.jboss.org/browse/WFCORE-1394 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Martin Simka > Assignee: Martin Simka > Fix For: 2.1.0.CR2 > > > Default maxPermgen size is added when {{jvm}} element isn't specified in domain.xml/host.xml and warning is logged. > {code:xml} > <server-group name="main-server-group" profile="default"> >  > <socket-binding-group ref="standard-sockets"/> > </server-group> > {code} > {noformat} > WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: null > {noformat} > It happens because default is defined in [JvmElement.java#L76|https://github.com/wildfly/wildfly-core/blob/master/h...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-19) Add KeyCloak based realm implementation.

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-19?page=com.atlassian.jira.plugin.sys... ] Pedro Igor edited comment on ELY-19 at 3/14/16 12:29 PM: --------------------------------------------------------- [~darranl], I think we can close this issue. The reason is that Keycloak integration is all about implementing an authentication mechanism based on Elytron HTTP API. Not sure if we really need a security realm for Keycloak, but maybe a different type of realm that can deal with JWT tokens. I've already implemented an initial version of a JWT-based realm, which uses a {{BearerTokenEvidence}} to pass the JWT to the security realm and creates identities from it. Pretty much what we have in {{OAuth2SecurityRealm}}, but using JWTs instead of a JSON response from the token introspection endpoint. Any thoughts ? was (Author: pcraveiro): [~darranl], I think we can close this issue. The reason is that Keycloak integration is all about implementing an authentication mechanism based on Elytron HTTP API. Not sure if we really need a security realm for Keycloak, but maybe a different type of realm that can deal with JWT tokens. I've already implemented an initial version of a JWT-based realm, which uses a ```BearerTokenEvidence``` to pass the JWT to the security realm and creates identities from it. Pretty much what we have in ```OAuth2SecurityRealm```, but using JWTs instead of a JSON response from the token introspection endpoint. Any thoughts ? > Add KeyCloak based realm implementation. > ---------------------------------------- > > Key: ELY-19 > URL: https://issues.jboss.org/browse/ELY-19 > Project: WildFly Elytron > Issue Type: Sub-task > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Fix For: 1.1.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-446) Additional fields on SecurityIdentity

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-446?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-446: --------------------------------- Credential forwarding should cover the following scenarios: * Propagating a clear password (like old JAAS/PicketBox propagation), either from the stored identity or discovered during the mechanism execution (the latter will require a separate enhancement to provide an API by which mechanisms may share this information) * Propagating stored credentials for GSS mechanisms (e.g. Kerberos) * Propagating stored credentials for other mechanisms (e.g. tokens of various kinds) And the following requirements: * Stored credential propagation has to be accessible from an AuthenticationConfiguration to support outflow via PeerIdentity and other means * Stored credentials must only be accessible to suitably privileged code > Additional fields on SecurityIdentity > ------------------------------------- > > Key: ELY-446 > URL: https://issues.jboss.org/browse/ELY-446 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: David Lloyd > Assignee: David Lloyd > > The following useful properties could be added to SecurityIdentity: > * Identity creation time (the time when the identity itself is created, whether by login or by run-as) > * Authentication information, including: > ** Login timestamp (the time of the original authentication) > ** Login mechanism & kind (SASL/HTTP/TLS etc.) > ** Login protocol (HTTP/Remoting/etc.) incl. enclosing TLS information if any > * Authentication identity information, including: > ** Original authentication name > ** Authentication forwarding credential(s) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-431) Improve Elytron HTTP API/SPIs to support a broader range of authentication mechanisms

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-431?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-431: --------------------------- Fix Version/s: 1.1.0.Beta5 > Improve Elytron HTTP API/SPIs to support a broader range of authentication mechanisms > ------------------------------------------------------------------------------------- > > Key: ELY-431 > URL: https://issues.jboss.org/browse/ELY-431 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Affects Versions: 1.0.2.Final > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta5 > > > This is task is being driven by the requirements around Keycloak and Elytron integration, which will provide as a result a baseline to implement a Keycloak OIDC adapter based on Elytron HTTP API and SPI. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-19) Add KeyCloak based realm implementation.

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-19?page=com.atlassian.jira.plugin.sys... ] Pedro Igor commented on ELY-19: ------------------------------- [~darranl], I think we can close this issue. The reason is that Keycloak integration is all about implementing an authentication mechanism based on Elytron HTTP API. Not sure if we really need a security realm for Keycloak, but maybe a different type of realm that can deal with JWT tokens. I've already implemented an initial version of a JWT-based realm, which uses a ```BearerTokenEvidence``` to pass the JWT to the security realm and creates identities from it. Pretty much what we have in ```OAuth2SecurityRealm```, but using JWTs instead of a JSON response from the token introspection endpoint. Any thoughts ? > Add KeyCloak based realm implementation. > ---------------------------------------- > > Key: ELY-19 > URL: https://issues.jboss.org/browse/ELY-19 > Project: WildFly Elytron > Issue Type: Sub-task > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Fix For: 1.1.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2016