+1 as well. Regarding authentication I remember SCIM spec leaves it open but suggests using oauth bearer tokens. Would be good to keep sync with Bill to not duplicate oauth work between PL and his effort. On 05/21/2013 02:56 PM, Pedro Igor Silva 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&gt; To: "security-dev >> > \&quot;security-dev(a)lists.jboss.org\&quot;&quot; <security-dev(a)lists.jboss.org&gt; > 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 > > _______________________________________________ security-dev mailing > list security-dev(a)lists.jboss.org > 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 > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

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&gt; 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&gt; > To: "security-dev >> \&quot;security-dev(a)lists.jboss.org\&quot;&quot; <security-dev(a)lists.jboss.org&gt; > 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 > > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > 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

On May 22, 2013, at 6:34 AM, Shane Bryzak <sbryzak(a)redhat.com <mailto:sbryzak@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.

> > [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&lt;psilva(a)redhat.com&gt; 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&quot;&lt;sbryzak(a)redhat.com&gt; >>> To: "security-dev >> \&quot;security-dev@lists.jboss.org\&quot;&quot;&lt;security-dev(a)lists.jboss.org&gt; >>> 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

What do you need to intercept? endpoint invocation or more? On 22 May 2013, at 14:33, Anil Saldhana <Anil.Saldhana(a)redhat.com&gt; 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&gt; 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&gt; >>>> 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&gt; >>>>> >>>>> To: "security-dev >> \ >>>>> &quot;security-dev(a)lists.jboss.org\&quot;&quot; <security-dev(a)lists.jboss.org&gt; >>>>> >>>>> 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 >>>>>

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&gt; 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&gt; 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&gt; 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&gt; >>>>>> 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&gt; >>>>>>> >>>>>>> To: "security-dev >> \ >>>>>>> &quot;security-dev(a)lists.jboss.org\&quot;&quot; <security-dev(a)lists.jboss.org&gt; >>>>>>> >>>>>>> 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 _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev