PicketLink Website
by Anil Saldhana
Hi All,
Deepali and I were discussing on Tuesday that we should revamp the
PicketLink community site to reflect the work we are doing with PL3.
The website needs an overhaul as some of the material is dated. :)
Looking toward Aerogear, JDF and others for inspiration in look and feel.
Regards,
Anil
12 years, 12 months
REST API for user provisioning
by Anil Saldhana
Hi All,
now that we have an excellent IDM subsystem as part of PicketLink3,
we need to next look at incorporating SCIM
(http://www.simplecloud.info/), a set of standards surrounding REST API
for Cloud Provisioning. SCIM is part of the IETF.
Probably in the PicketLink 3.1+ timeframe.
Regards,
Anil
12 years, 12 months
Undertow in AS8
by Anil Saldhana
Hi All,
PL2 SAML support contains some Tomcat valves that do the SAML
handshake for Web Browser SSO. Since Undertow is going to be the web
container for AS8 and beyond, there is a need to figure out the
container security integration for Undertow. This is something I need
to keep an eye on.
PL3 will have SAML support. Container Integration (Tomcat,Undertow) will
happen in a pl/container-bindings project with separate jars.
Regards,
Anil
13 years
XACML 3.0
by Siamak Sadeghianfar
Hi,
Are there any plans for XACML 3.0 in PicketBox?
The XACML 2.0 implementation is not really merged into PicketBox and
despite the name, is the old jboss-security stuff. Is there any roadmap
available about what is going to happen to it?
Best Regards,
Siamak Sadeghianfar
13 years
Some thoughts on PL Subsystem
by Stian Thorgersen
I've had a look at https://community.jboss.org/wiki/PicketLink3Subsystem and also had a bit of a play with it. It's starting to look really good. I've just got a few suggestions:
Suppress logging
----------------
At the moment there's a lot of logging at info level produced by the subsystem, this is mostly Hibernate. It would be great if we could somehow manage to suppress this logging output, might be problematic though as Hibernate logs this stuff at INFO level when it really should be DEBUG. There's also a few WARN's we might want to look into fixing.
JNDI names in standalone.xml
----------------------------
I think it makes sense to use the same format for JNDI names as the datasource element, since folks will already be used to that. So I suggest we change it slightly to look like this:
<jpa-store data-source=”java:jboss/datasources/ExampleDS" ...>
<identity-management jndi-name="java:picketlink/ExampleIDM" ...>
* Full jndi name (including java:) and use jndi-name instead of jndi-url
Manifest.mf
-----------
We need to make sure it works when including org.picketlink, org.picketlink.idm, etc in manifest.mf as well as jboss-deployment-structure.xml. The documentation should also reflect this. One thing I also thought of is that for the future it may be nice to have something that detects PicketLink usage in a deployment and automatically adds dependencies as required. For example if deployment uses @IdentityManager, @Identity, etc. annotations.
JNDI
----
@Resource doesn't require CDI, so it should be possible to do the following without CDI (and without org.picketlink.core):
@Resource(lookup = "java:/picketlink/DevIdentityManager")
private IdentityManagerFactory identityManagerFactory;
I was wondering if we wanted to have the IdentityManager available in JNDI as well?
CDI
---
I was thinking about a nice way to do the CDI support of injecting a 'default' IdentityManager. I propose adding the attribute 'default' to the 'identity-management' element (<identity-management default="true" ...>). We should throw a warning if a user has specified multiple, then we just pick one (first one?).
This does mean that if a 'identity-management' has the 'default' attribute set on it all deployments will by default have that IdentityManager injected into it. We also need a way for users to override this on a per-deployment basis. Can we easily detect if a deployment contains configuration for a IdentityManager itself?
Further we need to have a way for a user to specify which IdentityManager to inject. I think this should be done based on the 'alias' attribute and not the 'jndi-name', as we should leave jndi completely out of the picture for CDI (resource-ref in web.xml/ejb.xml should be used for JNDI lookup, InitialContext#lookup and @Resource, I find it confusing to use this for CDI). I propose that we use the ServiceRegistry to retrieve the IdentityManagerFactory service based on the alias specified by a @Alias qualifer:
@Inject
@Alias(“development”)
private IdentityManager identityManager;
Obviously users should also be able to add their own qualifiers, I think this should work:
@Inject @Alias(“development”)
@Produces @Development
private IdentityManager identityManager;
One alternative to the above is to change 'alias' to 'name' then we could use the standard @Named annotation instead of @Alias.
Custom Entity Classes
---------------------
Personally I don't like the idea of custom entity classes (and persistence.xml) being deployed as JavaEE deployments (i.e. standalone/deployments). This is also problematic for sub-systems that wants to use the IDM if they need to use custom entity classes (there's a good chance we'll need this for EventJuggler). I also think this will be problematic if multiple deployments uses the same IdentityManager.
One idea I had was that we could create a module that contains the custom Entity classes, then specify that on the 'jpa-store' element:
<jpa-store data-source=”java:jboss/datasources/ExampleDS" custom-entity-module='org.company.acme.pl' />
The module 'org.company.acme.pl' would contain a single jar with the Entity classes. When 'custom-entity-module' is used we include that module instead of 'org.picketlink.idm.schema' module when creating the EMF + we should be able to detect the correct classes using the @IDMEntity.
13 years
[PicketLink] - Module Organization
by Pedro Igor Silva
Hi All,
I was thinking about the best way to organize the PicketLink libraries with the AS module structure.
Now that PicketLink have some sub-projects, I was wondering if we should have a single module for all libraries (core, idm, federation, oauth, etc):
org/picketlink/main
- core.jar
- idm.jar
- federation.jar
- etc.
Or if is better to have different modules for each project:
org/picketlink/core/main
- core.jar
org/picketlink/idm/main
- idm.jar
org/picketlink/federation/main
- federation.jar
Any thoughts ?
Regards.
Pedro Igor
13 years
PicketLink - Thread Safety
by Anil Saldhana
Hi All,
for all the classes from PicketLink that developers are going to use,
we should make it known whether the class is threadsafe or not. If any
of the classes are not threadsafe, we should make it known in the javadocs.
Thoughts?
Regards,
Anil
13 years
