It should do, it should be applied to any endpoint on JBoss, in which CDI is enabled.
On 22 May 2013, at 15:08, Anil Saldhana <Anil.Saldhana(a)redhat.com> wrote:
Almost always endpoint invocation. Will the CDI interceptor help
here?
On 05/22/2013 09:06 AM, Pete Muir wrote:
> What do you need to intercept? endpoint invocation or more?
>
> On 22 May 2013, at 14:33, Anil Saldhana <Anil.Saldhana(a)redhat.com> wrote:
>
>> On 05/22/2013 06:54 AM, Anil Saldhana wrote:
>>>
>>> On May 22, 2013, at 6:34 AM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
>>>
>>>> I've spent some time today reviewing the RESTEasy reference docs [1]
and source code [2]. Its primary security focus seems to be on OAuth and request-signing,
which I'm happy to steer clear of for the time being and instead concentrate on
building a JavaScript-based BASIC and DIGEST authentication client. I think we still need
to start a separate discussion in conjunction with Bill for the OAuth topic and where
PicketLink fits into this, perhaps next week sometime we could even have a call or hangout
to work out our next steps.
>>>>
>>>> Back on topic for PicketLink though, would it be ok Anil if we went ahead
and renamed the SCIM module to REST, and began prototyping the JavaScript client and
extended REST services there?
>>> Cool. I think we should aim scim beyond the 2.5 release.
>> Also while we are on the REST security topic, I think we will need a JAX-RS
interceptor to introduce security into the apps. But the interceptor is standardized in
JAX-RS 2.0 (EE7). For EE6 apps, I think we will have to use RESTEasy interceptor (which
means a deep coupling).
>>>> [1]
http://docs.jboss.org/resteasy/docs/3.0-beta-5/userguide/html_single/inde...
>>>> [2]
https://github.com/resteasy/Resteasy/tree/master/jaxrs/security
>>>>
>>>> On 21/05/13 23:27, Anil Saldhana wrote:
>>>>> Rest module can have scim as well as oauth base. We need to ensure
that we do not conflict with RESTEasy as it has many security features.
>>>>>
>>>>> On May 21, 2013, at 7:56 AM, Pedro Igor Silva
>>>>> <psilva(a)redhat.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> +1.
>>>>>>
>>>>>> But regarding the two set of RESTful services, maybe we can have
only a SCIM set where the PicketLink additional features can be handled as extensions to
the base schema.
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Shane Bryzak"
>>>>>> <sbryzak(a)redhat.com>
>>>>>>
>>>>>> To: "security-dev >> \
>>>>>> "security-dev(a)lists.jboss.org\""
<security-dev(a)lists.jboss.org>
>>>>>>
>>>>>> Sent: Tuesday, May 21, 2013 5:22:06 AM
>>>>>> Subject: [security-dev] PicketLink SCIM Module
>>>>>>
>>>>>> I've been reviewing the capabilities of the SCIM module
(which are defined by the SCIM specification [1]) and someone correct me if I'm wrong,
but it only seems to provide a subset of the features that we support in PicketLink.
Specifically missing are authentication, and support for the extended relationship types
(basically everything besides group membership). I'm wondering if it might be worth
providing a PicketLink REST module instead, which would provide two sets of RESTful
services; the first being a SCIM-compliant service, the second being a more proprietary
service that exposes all of the capabilities of PicketLink.
>>>>>>
>>>>>> On top of this, I think it would be of huge benefit to provide
both Java and JavaScript clients to consume both services. Anil has already implemented a
Java-based SCIM client in the SCIM module, but imagine if we provided PicketLink
JavaScript scripts that web application developers could drop into their app - this would
be a huge development time saver. I'm also thinking that the JavaScript clients should
support a variety of authentication mechanisms; BASIC, DIGEST, X509, user/password, OAuth,
etc. This is kind of uncharted territory for me (REST-based auth) so any feedback or
opinions on this would be appreciated.
>>>>>>
>>>>>> Shane
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>>
http://www.simplecloud.info/specs/draft-scim-api-01.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
https://lists.jboss.org/mailman/listinfo/security-dev
>>>>>>
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev