[security-dev] Some thoughts on PL Subsystem
Pedro Igor Silva
psilva at redhat.com
Thu Apr 11 11:30:56 EDT 2013
So, the updated list would be:
1) Rename the attribute jndi-url to jndi-name;
2) Publish in JNDI an IdentityManager for each realm.
3) Support custom entities using a attribute to specify a module from
where the @IDMEntity classes are + persistence.xml;
----- Original Message -----
From: "Pete Muir" <pmuir at redhat.com>
To: "Stian Thorgersen" <stian at redhat.com>
Cc: "Pedro Igor Silva" <psilva at redhat.com>, security-dev at lists.jboss.org
Sent: Thursday, April 11, 2013 12:22:54 PM
Subject: Re: [security-dev] Some thoughts on PL Subsystem
If you come up with one, let me know - this is something no one has solved in any situation ;-)
On 11 Apr 2013, at 16:11, Stian Thorgersen <stian at redhat.com> wrote:
> I think for now we should drop the default attribute + @Realm, and only support @Resource (i.e. user has to create @Produce @Resource to be able to inject IdentityManager for sub-system). If we can think of a nice way to inject @IdentityManager allowing user to specify correct identity-management and realm that would be great, but I don't think we have an approach to this at the moment.
>
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva at redhat.com>
>> To: "Pete Muir" <pmuir at redhat.com>
>> Cc: "Stian Thorgersen" <stian at redhat.com>, security-dev at lists.jboss.org
>> Sent: Thursday, 11 April, 2013 3:49:35 PM
>> Subject: Re: [security-dev] Some thoughts on PL Subsystem
>>
>> So, if you guys agree we can start working on the following improvements:
>>
>> 1) Rename the attribute jndi-url to jndi-name;
>> 2) Publish in JNDI an IdentityManager for each realm. That would look
>> like this:
>>
>> picketlink/MyIdentityManagerFactory
>> picketlink/MyIdentityManagerFactory/default (for the default realm)
>> picketlink/MyIdentityManagerFactory/SomeRealm
>> picketlink/MyIdentityManagerFactory/AnotherRealm
>>
>> 3) Add the default attribute for the identity-management element and
>> handle it properly
>>
>> 4) Supports a @Realm annotation in order to allow the injection of
>> IdentityManager that maps to a specific realm
>>
>> 5) Support custom entities using a attribute to specify a module from
>> where the @IDMEntity classes are + persistence.xml;
>>
>> What do you think ?
>>
>> ----- Original Message -----
>> From: "Pete Muir" <pmuir at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Pedro Igor Silva" <psilva at redhat.com>, security-dev at lists.jboss.org
>> Sent: Thursday, April 11, 2013 11:16:14 AM
>> Subject: Re: [security-dev] Some thoughts on PL Subsystem
>>
>>
>> On 11 Apr 2013, at 14:35, Stian Thorgersen <stian at redhat.com> wrote:
>>
>>> For custom entity classes I have two use cases in mind that we need should
>>> test/support:
>>>
>>> * Layered product that needs to use custom entity classes for sub-systems -
>>> in this case there's no JavaEE deployments and the entity classes needs to
>>> be within a module. It's also fairly cumbersome to create an
>>> EntityManagerFactory from a subsystem so I don't think that should be
>>> required
>>>
>>> * Two applications sharing the same custom entity classes - for example
>>> there's a main web app that contains the custom entity classes and the
>>> persistence.xml, then there's a utility war that contains one single
>>> @Startup @Singleton that is used to create some initial users - the
>>> utility war would load a lot quicker than the main web app, so the EMF may
>>> not be registered in JNDI in time
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: security-dev at lists.jboss.org
>>>> Sent: Thursday, 11 April, 2013 2:04:17 PM
>>>> Subject: Re: [security-dev] Some thoughts on PL Subsystem
>>>>
>>>> Hi Stian,
>>>>
>>>> Your thoughts make a lot of sense to me. Comments inline.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>> To: security-dev at lists.jboss.org
>>>>> Sent: Thursday, April 11, 2013 9:37:59 AM
>>>>> Subject: [security-dev] Some thoughts on PL Subsystem
>>>>>
>>>>> 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.
>>>>
>>>> Review the logging and messages is one of the things in our TODO list.
>>>>
>>>>>
>>>>>
>>>>> 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
>>>>
>>>> +1 for that. Not sure from where I got the jndi-url if the jndi-name is
>>>> like
>>>> a pattern used by other subsystems :)
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> +1. I like the idea, ans also mark them as IDM or Core deployments and
>>>> handle
>>>> them properly.
>>>>
>>>>>
>>>>> 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?
>>>>
>>>> The problem in publishing the IdentityManager in JNDI is related with
>>>> realms.
>>>> If the IDM config has multiple realms which one should we put ? The
>>>> default
>>>> ?
>>>>
>>>> Give to users the IdentityManagerFactory instead, allow them to use their
>>>> configurations as they want.
>>>>
>>>> One thing that I thought about that is if is a good idea to publish all
>>>> IdentityManager instances for each configured realm. So, if the IDM config
>>>> defines multiple realms, we publish a IdentityManager instance for each of
>>>> them. But as we discussed this may become messy.
>>
>> I think this is the right approach.
>>
>>>>
>>>> What do you think ?
>>>>
>>>>>
>>>>>
>>>>> 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?).
>>>>
>>>> I think we had some discussion about that. I'm +1 for the default
>>>> attribute.
>>>>
>>>> Ideally, we should throw an exception if multiple configurations are
>>>> provided
>>>> with the default attribute, IMO.
>>
>> Agreed, this should be an error.
>>
>>>>
>>>>>
>>>>> 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?
>>>>
>>>> The IMF can be obtained today in the following ways:
>>>>
>>>> 1) From JNDI (@Resource, InitialContext, etc)
>>>> 2) Providing a @Producer that produces a IdentityConfiguration. In this
>>>> case the deployment provides its own configuration, instead of using
>>>> the
>>>> subsystem config.
>>>> 3) When using the Core services, the deployment must specify a
>>>> web.xml#resource-ref. Otherwise the deployment must provides its own
>>>> configuration (normal usage of PicketLink Core)
>>>>
>>>> Considering 2), if no IdentityConfiguration is produced, we can
>>>> automatically
>>>> choose the default.
>>>>
>>>> Considering 3), if no web.xml at resource-ref is defined, we can
>>>> automatically
>>>> choose the default.
>>>>
>>>>>
>>>>> 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:
>>>>
>>>> If you look at the Infinispan subsystem, this is the way it works. Using
>>>> the
>>>> @Resource annotation to inject cachecontainers, etc.
>>>>
>>>> I like that because it is very simple, and requires very little from our
>>>> and
>>>> users side.
>>
>> This is also the approach the spec defines to access server resources.
>>
>>>>
>>>> We have a test case that shows how to use CDI qualifiers. It is quite
>>>> simple.
>>>>
>>>> But at the same time, I agree that use the name is more beautiful than the
>>>> jndi-name :).
>>>>
>>>> We can try that, if you want.
>>
>> We shouldn't do this, it encourages the CDI anti-pattern of using string
>> based qualifiers.
>>
>>>>
>>>>>
>>>>> @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;
>>
>> This won't work, CDI will give you a definition error. You need to use
>> @Resource to access server resources, or what Pedro suggests below.
>>
>>>>>
>>>>> One alternative to the above is to change 'alias' to 'name' then we could
>>>>> use
>>>>> the standard @Named annotation instead of @Alias.
>>>>
>>>> We are not injecting the IdentityManager anymore, but the
>>>> IdentityManagerFactory. The @Alias makes sense to get a IdentityManager
>>>> instance for a configured realm. Maybe we should consider @Realm, instead.
>>>>
>>>>>
>>>>>
>>>>> 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' />
>>
>> This should work IMO.
>>
>>>>>
>>>>> 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.
>>>>
>>>> The JPA store lets you use the EMF in two ways:
>>>>
>>>> 1) Using a embedded persistence unit. In this case you need only yo
>>>> provide the datasource. The built-in schema (pl-idm-schema) will be
>>>> used.
>>>> 2) Using your own persistence unit. In this case you need to expose your
>>>> EMF via JNDI.
>>>>
>>>> Regarding 2), you are not forced to deploy your persistence.xml as a
>>>> separated deployment. You can also use the persistence unit deployed with
>>>> your application.
>>>>
>>>> I'm going to create some tests so check a possible classloader issue when
>>>> using custom entity classes.
>>
>>
>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> security-dev mailing list
>>>>> security-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>>
>>>> _______________________________________________
>>>> security-dev mailing list
>>>> security-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
More information about the security-dev
mailing list