Refactoring of picketlink-integration-tests
by Ondra Lukas
Hi,
we would like to do some refactoring of PicketLink integration testsuite for easier QE testing with new versions of EAP. We have some ideas how to improve it and I want to ask you what do you think about that. Here is the list, we would like to:
1) change of configuration which running specified tests for specified container. It is currently set by @TargetContainers annotation. We prefer to using better usage of maven profiles and for instance Java subpackages according to profiles. Every subpackage will contain tests which will run only in that profile (for example org.picketlink.test.trust.tests.eap6 will contain tests for EAP6 profile). Tests which run in every profile will stay in current packages. Tests which run in more profiles (but not in all of them) will be added by include/exclude parameters of maven-failsafe-plugin.
Why?
It will be easier to configurate it for QE testing. We need some easy way how to see each test of some profile. Currently we have all tests together and it's quite uncomfortable. It will be simpler to add a new container too.
2) avoid use of Ant and try to rewrite it to maven (using Maven Resource Plugin etc.).
Why?
We want to have ability of setting properties from command line (which is not handled correctly by maven-antrun-plugin). Also we want to have only one type of configuration files.
3) create Arquillian's ServerSetupTasks for setting containters (setting security domains for testing etc.).
Why?
We want to avoid XSLT because it is sometimes out of work in diffrent type of JDKs.
4) remove "dist" folders from every container (/integration-tests/CONTAINER/dist) and remove distributions from dist. We will use only one dist folder which will be located in integration-tests folder.
Why?
If anybody is cloning picketlink-integration-tests from git, he have to clone distributions, but it take a lot of unnecessary time. We think that better way is have one empty folder for all distributions. User can input nedded distributions.
What do you think about that? Does anybody have any idea about improvement of picketlink-integration-tests testsuite?
Thanks,
Ondrej Lukas
13 years
PicketLink Usecase: SAML/GWT/REST Authentication
by Anil Saldhana
Hi All,
this is a use case solved by Eric Wittman of Project Overlord using
PicketLink.
Final Solution in Eric's words:
Use-case is: GWT UI app is protected by SAML SSO. The UI makes GWT RPC
calls back to itself. The UI RPC servlets (server-side) then make REST
calls to a set of REST services hosted in another web application, using
SAML tokens for authentication.
JIRA: https://issues.jboss.org/browse/DTGOV-11
Background:
Eric had gotten his GWT UI App to use SAML SSO using PicketLink. He was
looking for ways to now make calls from the GWT app to REST services on
RESTEasy without re-authentication.He needed to get this usecase working
with PicketLink and RESTEasy bundled in EAP6. During discussions and
future plan, it was decided to use OAuth for REST services and look at
SAML Bearer Token Profile for guidance.
Solution:
Since RESTEasy authentication can use JAAS authentication, Eric wrote a
login module for SAML bearer tokens.
https://github.com/Governance/overlord-commons/blob/master/overlord-commo...
I created a JIRA issue in PicketLink to migrate this login module:
https://issues.jboss.org/browse/PLINK-165
This login module will be available in PicketLink v2.5.0
https://github.com/anilsaldhana/picketlink-bindings/blob/0808a9916093af60...
I wanted to open a thread for discussion on this. I am unsure if other
projects have similar needs but this use case is pretty awesome to share
here.
Regards,
Anil
13 years
query role mappings of a particular partition
by Bill Burke
If I have Users defined in one partition (a realm) and roles defined in
another partition (Tier), how do I:
* grant a tier role to a realm user?
* query grants of a user for a specific tier?
I guess I have to query for all the Grants for a particular user, then
filter them out based on the Role's partition?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
concurrent access to IDM
by Bill Burke
How should concurrent access to IDM storage be handled? Right now I see
a lot of concurrency issues in the code that will pretty much force you
to create an IdentityManagerFactory and IdentityManager per request.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
PicketLink IDM Relationships and SASL Authorizations
by Darran Lofthouse
Within SASL there is a capability where during the authentication phase
the agent being authenticated can request that subsequently they want
the authorization privileged of another agent.
The loading the identity of the agent being requested is fine but at the
moment I am looking within PicketLink IDM at how this one agent being
able to run as another agent can be modeled.
I can see using a custom relationship how it should be fairly easy to
model a 1:1 mapping of users that an 'impersonate' each other but I have
a few additional scenarios that could also be needed so wanted to look
for ideas on how to support all of these simultaneously.
- A single agent can impersonate a single agent.
- A single agent can impersonate any user that is a member of a
specified group.
- A member of a specific group can impersonate a single agent.
- A member of one group can impersonate an agent of another (or same)
group.
As mentioned in IRC over the last couple of days having some form of
permissions check API in the IDM for the non AS processes feels like it
would fit this really well - however at the moment I can perform this
check outside of any permissions API so just looking for ideas how it
could be achieved.
Regards,
Darran Lofthouse.
13 years
PicketLink IDM - Replace Default Credential Handler
by Darran Lofthouse
Investigating SASL integration with PicketLink IDM shows the Plain
mechanism working fine with a fairly default set up - however as I am
adding support for the Digest based mechanism I seem to need to be able
to replace the default CredentialHandler for UsernamePasswordCredentials.
On validating a request I don't believe that the code making use of the
IDM should be aware of any of the storage details, so now I have users
that could be stores with a plain text password or a pre-prepared ha1 hash.
What I would like is to add one CredentialHandler that can handle
requests to validate both plain text passwords and digest credentials
and decide internally how to handle them based on which one is currently
associated with the agent.
My credential handler is registered as it allows me to add my new custom
DigestPassword credential but it is not being used for the validation of
a UsernamePasswordCredentials object.
Is there anything else I need to do to disable the default implementation?
Regards,
Darran Lofthouse.
13 years
Example LDAP Stores
by Darran Lofthouse
Hi all,
Just looking for some LDAP examples, are there any example
configurations using PicketLink IDM against either Active Directory or
FreeIPA?
Also I am interested in verifying some Kerberos / SPNEGO authentication
for SASL and Undertow with PicketLink IDM - have either of these been
tested so far?
Regards,
Darran Lofthouse.
13 years
