recommended library for SAML auth for WF9+?
by Karl Pietrzak
Hi there, everyone.
With the deprecation of Picketlink, what's the recommended library for SAML
authentication? It seems Keycloak isn't included in WF9.0.1Final or
WF10.0CR2, but Picketlink still is. Should we migrate to Spring
Security/Apache Shiro/etc.?
Thoughts?
--
Karl
10 years, 9 months
jersey custom annotation injection
by alex orl
I m using Wildfly 9.0 and i need to build my custom annotation injection mechanism in order to inject my principal object.. My requirement is to work with Jersey 2.x.So i'm following the jersey reference guide at this link:
https://jersey.java.net/documentation/latest/ioc.html
But unluckily my injected principal object is always null. Someone asserts that is an inevitable conflict between the resteasy jax rs implementation embedded with wildfly and Jersey.So what the way to make jersey hk2 injection to work without conflicting with the wildfly weld?
Is there a way to implement the same custom injection with resteasy?thanks
10 years, 10 months
WildFly - encrypt datasource.
by Eduardo Medeiros
Hello Guys,
I would like to know if there is a road map to add a feature for encrypt
password from data sources using HAL console.
Nowadays, I know that this configuration is possible using the keytool and
vault.sh, but is a little bit hard and confused.
--
Thank you,
Eduardo Medeiros.
10 years, 10 months
Capabilities/requirements and deployments
by David M. Lloyd
While working on moving the EJB subsystem to support Elytron, I
encountered a dilemma regarding cap/req.
Elytron exposes security domains as capabilities. EJB deployments have
the ability to specify which security domain is used for authorization
purposes. This specification is by name.
The dilemma is:
1) Allow EJB deployments to directly reference security domain names,
thus implicitly causing the EJB subsystem to require all or none of the
security domains that are or could be configured
2) Require the EJB subsystem to declare (in the model) what security
domains it uses, thus requiring only security domains that are used
Option 1 seems disadvantageous because if EJB requires no domains, it is
possible to break deployments without getting so much as a warning, but
if it requires all, then you can never make significant changes to your
security domain configuration.
Option 2 requires an extra level of configuration, but on the other
hand, it also allows tricks like providing a "local" name for each
security domain which the deployment can reference, which grants a small
but potentially useful degree of flexibility, and it has a better degree
of in-model referential integrity.
Option 2 also requires that any run-time operation to remove a security
domain from the EJB subsystem be verified against current deployments.
I wonder if we can do this with runtime-only resources and cap/req too?
I guess I've just talked myself into Option 2, but I'm thinking that
this is not going to be the only case like this as we further develop
cap/req-enabled subsystems.
Thoughts?
--
- DML
10 years, 10 months
Want to contribute
by Utkarsh Tiwari
Hello!
I would like to contribute to Jboss community.I know familiar with
Java. Could anyone here help me get started?
regards-
Utkarsh
10 years, 10 months
Redesigning http-upgrade configuration for management
by Emmanuel Hugonnet
Hi,
This is for management interfaces only.
We need a capability to cover the fact that some management interfaces may provides jboss-remoting endpoints to be used by JMX.
The native-interface provides this capability at the resource level, so this is nice and straightforward.
Currently making an http-interface http-upgrade-enabled is done through the well named 'http-upgrade-enabled' attribute.
But because of the use of an attribute we have no nice standard way to register the capability.
One way to do that would be to use a child resource, "http-upgrade-support=on" to define the fact that this http-interface supports upgrade.
We could then move the code and services associated with this support to the addHandler and removeHandler.
To keep backward compatibility :
- for the add / remove of current resource :
it is easy to add a new step to add the new resource on the http-interface addHandler, and do the same for removal.
- for the beloved http-upgrade-enabled attribute which is writeable but doesn't really do anything until the interface is restarted.
Of course it could get deprecated but we would still have a writeable attribute that represents a duplicate state of the child resource.
We may want to use the write-attribute handler on this attribute to call the resource ops without impacting the services, just changing the
model.
What do you think ?
10 years, 10 months
WildFly Arquillian for Domain Servers
by James Perkins
Does anyone use wildfly-arquillian with domain servers? If so does it work?
I was processing pull request for the wildfly-arquillian [1] project.
During the process I found a pull requestion for an issue with using
arquillian on domain servers [2]. This led me to look at the to look at the
domain adapters. Looking through the code it looks quite out of date and
potentially wrong in some places. I started updating and noticed that the
tests were ignored. I re-enabled them and realized the adapter doesn't seem
to work at all.
The main issue seems to be that deployments are not rolled out to the
servers. If I change the deployment plan to rollback on error it has an
error message that states "WFLYDC0022: Operation failed or was rolled back
on all servers.". No other reason. I can start the same server used in
domain mode and execute CLI commands or use an operation identical to the
one created by the deployment plan and all seems to work fine. I assume
this issue is unique to arquillian.
I'm at the point where I don't want to invest anymore time if no one is
using arquillian for domain servers. If anyone is using it and has an
example application that you could share that would be helpful :)
I propose if no one is using it, we scrap it.
If people *are* using it I propose we do a redesign it a bit. There's
mainly some things exposed I don't think should be exposed. I could keep
compatibility too fairly easily. It would be about the same amount of work
either way I think.
If anyone else has other ideas I'm open to that as well.
[1]: https://github.com/wildfly/wildfly-arquillian
[2]: https://issues.jboss.org/browse/ARQ-1971
--
James R. Perkins
JBoss by Red Hat
10 years, 10 months
