Bill, I think we should start collecting the requirements some place. List out some high level topics as to what this project will do etc. The teams (Aerogear, GateIn etc) can give some pointers to what they like to have. We can then figure out the goodies the project will provide. Regards, Anil On 04/18/2013 09:44 AM, Bill Burke wrote: > Hey all, > > Mark Little approached me about starting a new project to provide an > SSO/OAuth2 solution for browser apps and RESTful web services. We've > gotten some buy-in/signoff from Anil, but I'd like to get buy-in/signoff > from Boleslaw especially and the rest of you. > > The idea is to provide an integrated SSO/OAuth2 solution for browser > apps and RESTful web services that can be used as a plugin for AS, a > standalone auth server, a cloud auth server, and/or a cloud SaaS. The > end product being something hosted on OpenShift and usable by anybody. > > I've started a requirements document and really need help rounding it out: > > https://community.jboss.org/wiki/ResteasySkeletonKeyWebSSOOAuth > > I also need help on the division of labor, if any with the Picketlink > team, or any individual on this team. I'm fine doing all the work, > delegating pieces to individuals, and/or reusing parts of Picketlink. > What should the division of labor be? My first thought is that I'd > build the service wholly or partially on the IDM API you all have been > working on. That way you guys could focus on storage and federation > (i.e. with LDAP, et. al.) and I could focus on UI, service, and protocol > aspects. > > Also, as most of you already know. I've already done a ton of work so far: > > http://docs.jboss.org/resteasy/docs/3.0-beta-4/userguide/html/oauth2.html > > Previously I had also even started prototyping a cloudable IDP service > using Infinispan as a backend store. > > https://github.com/resteasy/Resteasy/tree/master/jaxrs/security/skeleton-... > > When the project is started, I'll be creating a new github project. I'd > like to name the project "Resteasy Skeleton Key" or "Picketlink Skeleton > Key". > > Thoughts? Concerns? Ideas? Insults? Whines? Cheers? Trash Talk? Once > things get moving we'll also be talking to PM and the Cloud BU. > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

Bill, there is water everywhere here in Chicago. Major flooding. I have not looked at anything. On 04/18/2013 09:47 AM, Bill Burke wrote: > Anil, did you not see the link below? The one where I said I started a > requirements document? > > On 4/18/2013 10:45 AM, Anil Saldhana wrote: >> Bill, >> I think we should start collecting the requirements some place. List >> out some high level topics as to what this project >> will do etc. The teams (Aerogear, GateIn etc) can give some pointers to >> what they like to have. We can then figure >> out the goodies the project will provide. >> >> Regards, >> Anil >> >> On 04/18/2013 09:44 AM, Bill Burke wrote: >>> Hey all, >>> >>> Mark Little approached me about starting a new project to provide an >>> SSO/OAuth2 solution for browser apps and RESTful web services. We've >>> gotten some buy-in/signoff from Anil, but I'd like to get buy-in/signoff >>> from Boleslaw especially and the rest of you. >>> >>> The idea is to provide an integrated SSO/OAuth2 solution for browser >>> apps and RESTful web services that can be used as a plugin for AS, a >>> standalone auth server, a cloud auth server, and/or a cloud SaaS. The >>> end product being something hosted on OpenShift and usable by anybody. >>> >>> I've started a requirements document and really need help rounding it out: >>> >>> https://community.jboss.org/wiki/ResteasySkeletonKeyWebSSOOAuth >>> >>> I also need help on the division of labor, if any with the Picketlink >>> team, or any individual on this team. I'm fine doing all the work, >>> delegating pieces to individuals, and/or reusing parts of Picketlink. >>> What should the division of labor be? My first thought is that I'd >>> build the service wholly or partially on the IDM API you all have been >>> working on. That way you guys could focus on storage and federation >>> (i.e. with LDAP, et. al.) and I could focus on UI, service, and protocol >>> aspects. >>> >>> Also, as most of you already know. I've already done a ton of work so far: >>> >>> http://docs.jboss.org/resteasy/docs/3.0-beta-4/userguide/html/oauth2.html >>> >>> Previously I had also even started prototyping a cloudable IDP service >>> using Infinispan as a backend store. >>> >>> https://github.com/resteasy/Resteasy/tree/master/jaxrs/security/skeleton-... >>> >>> When the project is started, I'll be creating a new github project. I'd >>> like to name the project "Resteasy Skeleton Key" or "Picketlink Skeleton >>> Key". >>> >>> Thoughts? Concerns? Ideas? Insults? Whines? Cheers? Trash Talk? Once >>> things get moving we'll also be talking to PM and the Cloud BU. >>>

Wow... looking at your requirements document I wonder if there is any aspect of identity not covered by your new project. Hard for me to reply much atm. as we are getting quite advanced prototyping with various elements that you listed already. And now you suddenly write that this is owned by your new project under RestEasy umbrella... Not sure what you expect to hear from us? We should do a call next week. Let me arrange it after the weekend to discuss this. Tomorrow I'm on PTO and hoped to start in 30min... ;) Bolek On 04/18/2013 04:44 PM, Bill Burke wrote: > Hey all, > > Mark Little approached me about starting a new project to provide an > SSO/OAuth2 solution for browser apps and RESTful web services. We've > gotten some buy-in/signoff from Anil, but I'd like to get buy-in/signoff > from Boleslaw especially and the rest of you. > > The idea is to provide an integrated SSO/OAuth2 solution for browser > apps and RESTful web services that can be used as a plugin for AS, a > standalone auth server, a cloud auth server, and/or a cloud SaaS. The > end product being something hosted on OpenShift and usable by anybody. > > I've started a requirements document and really need help rounding it out: > > https://community.jboss.org/wiki/ResteasySkeletonKeyWebSSOOAuth > > I also need help on the division of labor, if any with the Picketlink > team, or any individual on this team. I'm fine doing all the work, > delegating pieces to individuals, and/or reusing parts of Picketlink. > What should the division of labor be? My first thought is that I'd > build the service wholly or partially on the IDM API you all have been > working on. That way you guys could focus on storage and federation > (i.e. with LDAP, et. al.) and I could focus on UI, service, and protocol > aspects. > > Also, as most of you already know. I've already done a ton of work so far: > > http://docs.jboss.org/resteasy/docs/3.0-beta-4/userguide/html/oauth2.html > > Previously I had also even started prototyping a cloudable IDP service > using Infinispan as a backend store. > > https://github.com/resteasy/Resteasy/tree/master/jaxrs/security/skeleton-... > > When the project is started, I'll be creating a new github project. I'd > like to name the project "Resteasy Skeleton Key" or "Picketlink Skeleton > Key". > > Thoughts? Concerns? Ideas? Insults? Whines? Cheers? Trash Talk? Once > things get moving we'll also be talking to PM and the Cloud BU. >

Bolek - I think we just got to figure out between the teams how we are going to distribute the pieces and reduce overlap as much as possible. We will need REST based services using RESTEasy and security bits delivered via PicketLink. What Bill wants to do is more like an infrastructure/service that drives sso/oauth2. He has been on it from a long long time now. If there is something you guys are doing right now that has major overlap with Bill's goals, we need to hash it out a bit. We should host almost all of the security bits in PicketLink umbrella if possible. On 04/18/2013 10:35 AM, Bolesław Dawidowicz wrote: > Wow... looking at your requirements document I wonder if there is any > aspect of identity not covered by your new project. > > Hard for me to reply much atm. as we are getting quite advanced > prototyping with various elements that you listed already. And now you > suddenly write that this is owned by your new project under RestEasy > umbrella... Not sure what you expect to hear from us? > > We should do a call next week. Let me arrange it after the weekend to > discuss this. Tomorrow I'm on PTO and hoped to start in 30min... ;) > > Bolek > > On 04/18/2013 04:44 PM, Bill Burke wrote: >> Hey all, >> >> Mark Little approached me about starting a new project to provide an >> SSO/OAuth2 solution for browser apps and RESTful web services. We've >> gotten some buy-in/signoff from Anil, but I'd like to get buy-in/signoff >> from Boleslaw especially and the rest of you. >> >> The idea is to provide an integrated SSO/OAuth2 solution for browser >> apps and RESTful web services that can be used as a plugin for AS, a >> standalone auth server, a cloud auth server, and/or a cloud SaaS. The >> end product being something hosted on OpenShift and usable by anybody. >> >> I've started a requirements document and really need help rounding it out: >> >> https://community.jboss.org/wiki/ResteasySkeletonKeyWebSSOOAuth >> >> I also need help on the division of labor, if any with the Picketlink >> team, or any individual on this team. I'm fine doing all the work, >> delegating pieces to individuals, and/or reusing parts of Picketlink. >> What should the division of labor be? My first thought is that I'd >> build the service wholly or partially on the IDM API you all have been >> working on. That way you guys could focus on storage and federation >> (i.e. with LDAP, et. al.) and I could focus on UI, service, and protocol >> aspects. >> >> Also, as most of you already know. I've already done a ton of work so far: >> >> http://docs.jboss.org/resteasy/docs/3.0-beta-4/userguide/html/oauth2.html >> >> Previously I had also even started prototyping a cloudable IDP service >> using Infinispan as a backend store. >> >> https://github.com/resteasy/Resteasy/tree/master/jaxrs/security/skeleton-... >> >> When the project is started, I'll be creating a new github project. I'd >> like to name the project "Resteasy Skeleton Key" or "Picketlink Skeleton >> Key". >> >> Thoughts? Concerns? Ideas? Insults? Whines? Cheers? Trash Talk? Once >> things get moving we'll also be talking to PM and the Cloud BU. >> > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

On 4/18/2013 11:52 AM, Bolesław Dawidowicz wrote: > Ok, but first of all I would like to understand better where Bill is > aiming and what does he want to cover. From the requirements it looks > like everything tbh > Boleslaw. I told Markthat I didn't want to do this without signoff from both Anil and *YOU*. As Anil said, I've been working on OAuth2/REStful IDM for awhile now (Since September 2012) in some form or another and already have something being used by people. Resteasy has also had rudimentary OAuth1 support for years now. But, I don't want to compete with another JBoss project. To some degree, I don't want to step on any toes either, but I also want something usable! It seemed to me that you guys were already extremely busy with the IDM API, AS8 security SPI/AP rework, and all the other WS-*/Oasis specs. I saw Anil's hacked together, zero functionality IDP UI on OpenShift. It was clear he was busy with other things. You go to the Picketlink webpage and it looks nothing like a solution. Links to incomplete projects, unreleased code, incomplete requirements documents. What do you think should be done by this new project vs. Picketlink? I thought I would build something on top of: http://www.jboss.org/picketlink/IDM.html Isn't that your project Boleslaw? Your IDM project isn't a good enough division of labor/SPI between the two projects? You guys are already doing this? Or just planned on doing this? > We are very interested for example to have full OAuth2 support (server > side) in PL - even in subsystem. Better with whole SCIM implementation > and handy REST endpoints. So if this could be provided by Bill I'm more > then happy to benefit from his project in our identity related components. > SCIM is interesting for identity management, not so interesting or needed for auth or even app development. > I'm also interested to learn if Bill is aiming to cover full OAuth2 spec > in his implementation or only server side application flow. Because > otherwise it will be hard to reuse on our side and I imagine it will be > similar for AeroGear as well. > YOu need to specify what you mean by "server-side application flow only". OAuth from a client perspective (thirdparty or user agent) is really very simple. Its just a matter of the client of obtaining a token and transmitting it via a bearer token header. The code I currently ship with resteasy has an auth server, oauth thirdparty, and user examples. So, while I dont' cover every flow type in OAuth (specifically the "implicit" model as it is very insecure (see Facebook), I do cover the other modes. > What are the components and services that RestEasy would aim to deliver > What would be reusability of this work? > I've already spelled it out. I want a AS plugin, an auth server, and a cloud service with SaaS capability. It would be a separate project from Resteasy and would probably leverage it and Picketlink as needed. Is there an existing IDM server project I can build off from or contribute to? It is very unclear to me a) what you guys are working on b) what is available c) the direction of Picketlink, etc. As for *reusability* of this work...I'm really not interested in doing this project just for the sake of doing it. If there is going to be competing work in our BU, then, I'm not going to do this project. Yes, I plan to have separate maven modules for different types of functionality that can be reused. i.e. components like JWT. > If PicketLink is just internally consumed component by RestEasy aimed to > only handle storage it doesn't sound very appealing to us. > The current stuff I already have in Resteasy (linked earlier) delegates to Picketlink's legacy LoginModule infrastructure to perform auth. Its also limited because it can't get at any other metadata other than principal and roll mappings. Would be cool to be able to generate more complex tokens, add support for OAuth scope, things like that. Impossible without being able to pull information from a real identity repository.

On Apr 18, 2013, at 9:38 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > > On 4/18/2013 11:52 AM, Bolesław Dawidowicz wrote: >> Ok, but first of all I would like to understand better where Bill is >> aiming and what does he want to cover. From the requirements it looks >> like everything tbh >> > Boleslaw. I told Markthat I didn't want to do this without signoff from > both Anil and *YOU*. As Anil said, I've been working on OAuth2/REStful > IDM for awhile now (Since September 2012) in some form or another and > already have something being used by people. Resteasy has also had > rudimentary OAuth1 support for years now. But, I don't want to compete > with another JBoss project. To some degree, I don't want to step on any > toes either, but I also want something usable! I know your involvement in exploring OAuth and respect it. We were quite counting on reusing your work. Especially example that you shared in January was very interesting. I was mainly shocked with scope of your email as it announced whole new huge identity related project out of the sudden. A lot from your listed requirements I was expecting to see as part of PicketLink. I have also sent you email two weeks ego describing in which direction my team is looking at in quite detailed way - without reply. Therefore I assume you know and understand while I'm puzzled here. > It seemed to me that you guys were already extremely busy with the IDM > API, AS8 security SPI/AP rework, and all the other WS-*/Oasis specs. I > saw Anil's hacked together, zero functionality IDP UI on OpenShift. It > was clear he was busy with other things. You go to the Picketlink > webpage and it looks nothing like a solution. Links to incomplete > projects, unreleased code, incomplete requirements documents. > > What do you think should be done by this new project vs. Picketlink? I > thought I would build something on top of: > > http://www.jboss.org/picketlink/IDM.html > > Isn't that your project Boleslaw? Your IDM project isn't a good enough > division of labor/SPI between the two projects? You guys are already > doing this? Or just planned on doing this? I'm not really sure why are you referring to IDM in this way… PicketLink IDM was founded by me and Anil few years ago. 1.x failed to take off and I described the context too many times already to repeat it. I have done my best to contribute experience from the past into new PicketLink initiative that ended with current 3.x work that is happening here. Seeing all great work provided by Anil, Shane, Pedro, Bruno and others in recent months I find reference to "incomplete projects, unreleased code, incomplete requirements documents." quite unfair. There was a lot of feedback provided by many camps into requirements for PicketLink. Just to name JDF, AeroGear or Portal. I could dig out what you have replied me when I asked you to contribute to requirement document but I don't think it is worth my time and won't help this discussion. At some point I invested significant time to get different people involved and aware about new activity in PicketLink. Therefore in fairness you shouldn't bash this project like that if you ignored the opportunity to bring in your requirements. >> We are very interested for example to have full OAuth2 support (server >> side) in PL - even in subsystem. Better with whole SCIM implementation >> and handy REST endpoints. So if this could be provided by Bill I'm more >> then happy to benefit from his project in our identity related components. >> > SCIM is interesting for identity management, not so interesting or > needed for auth or even app development. > I admit SCIM is very simple but on this side as a standard REST API I find it pretty interesting >> I'm also interested to learn if Bill is aiming to cover full OAuth2 spec >> in his implementation or only server side application flow. Because >> otherwise it will be hard to reuse on our side and I imagine it will be >> similar for AeroGear as well. >> > YOu need to specify what you mean by "server-side application flow > only". OAuth from a client perspective (thirdparty or user agent) is > really very simple. Its just a matter of the client of obtaining a > token and transmitting it via a bearer token header. The code I > currently ship with resteasy has an auth server, oauth thirdparty, and > user examples. So, while I dont' cover every flow type in OAuth > (specifically the "implicit" model as it is very insecure (see > Facebook), I do cover the other modes. I mainly share concerns that Jay mentioned. >> What are the components and services that RestEasy would aim to deliver >> What would be reusability of this work? >> > I've already spelled it out. I want a AS plugin, an auth server, and a > cloud service with SaaS capability. It would be a separate project from > Resteasy and would probably leverage it and Picketlink as needed. Is > there an existing IDM server project I can build off from or contribute > to? It is very unclear to me a) what you guys are working on b) what is > available c) the direction of Picketlink, etc. What do you mean by AS plugin? How does it relates to subsystem and work that Darran is driving? I'm interested to see authentication capabilities (even full OAuth support) as part of PL Subsystem in AS. For general PL Roadmap I will leave reply to Anil. Around cloud, authentication and social I described you in which direction my team is looking. It was in email sent 2 weeks ago. I hoped for a reply. Again, if email failed we can try a call next week and I hope we can agree on how to proceed together. I suggest to take step back a bit and look at requirements and not which project is going to drive the implementation We need to also have more detailed discussions about provided components and their exact functionality. Then we could agree together which parts should happen in PL land and which should be shared and abstracted. > As for *reusability* of this work...I'm really not interested in doing > this project just for the sake of doing it. If there is going to be > competing work in our BU, then, I'm not going to do this project. Yes, > I plan to have separate maven modules for different types of > functionality that can be reused. i.e. components like JWT. It is great to hear. On my side I'm really against duplicating work. I think discussions that we had on this list in past few weeks are best proof. Instead of just hacking something around on our own we invested our time to help with subsystem work. Did you share with Pedro your needs around AS, server and authentication parts? I repeated it many times already - as a cofounder of PL IDM 1.x I'm especially interested in seeing wide adoption of PicketLink. Cross project collaboration is key here and I hope we won't loose this opportunity. >> If PicketLink is just internally consumed component by RestEasy aimed to >> only handle storage it doesn't sound very appealing to us. >> > > The current stuff I already have in Resteasy (linked earlier) delegates > to Picketlink's legacy LoginModule infrastructure to perform auth. Its > also limited because it can't get at any other metadata other than > principal and roll mappings. Would be cool to be able to generate more > complex tokens, add support for OAuth scope, things like that. > Impossible without being able to pull information from a real identity > repository. >

>> >> YOu need to specify what you mean by "server-side application flow >> only". OAuth from a client perspective (thirdparty or user agent) is >> really very simple. Its just a matter of the client of obtaining a >> token and transmitting it via a bearer token header. The code I >> currently ship with resteasy has an auth server, oauth thirdparty, and >> user examples. So, while I dont' cover every flow type in OAuth >> (specifically the "implicit" model as it is very insecure (see >> Facebook), I do cover the other modes. > > I mainly share concerns that Jay mentioned. > I've asked multiple times for clarification on what "mobile" security means. Especially since our mobile solution seems to be grounded in HTML 5 and HTTP requests.

Hey all, Mark Little approached me about starting a new project to provide an SSO/OAuth2 solution for browser apps and RESTful web services. We've gotten some buy-in/signoff from Anil, but I'd like to get buy-in/signoff from Boleslaw especially and the rest of you. The idea is to provide an integrated SSO/OAuth2 solution for browser apps and RESTful web services that can be used as a plugin for AS, a standalone auth server, a cloud auth server, and/or a cloud SaaS. The end product being something hosted on OpenShift and usable by anybody. I've started a requirements document and really need help rounding it out: https://community.jboss.org/wiki/ResteasySkeletonKeyWebSSOOAuth I also need help on the division of labor, if any with the Picketlink team, or any individual on this team. I'm fine doing all the work, delegating pieces to individuals, and/or reusing parts of Picketlink. What should the division of labor be? My first thought is that I'd build the service wholly or partially on the IDM API you all have been working on. That way you guys could focus on storage and federation (i.e. with LDAP, et. al.) and I could focus on UI, service, and protocol aspects. Also, as most of you already know. I've already done a ton of work so far: http://docs.jboss.org/resteasy/docs/3.0-beta-4/userguide/html/oauth2.html Previously I had also even started prototyping a cloudable IDP service using Infinispan as a backend store. https://github.com/resteasy/Resteasy/tree/master/jaxrs/security/skeleton-... When the project is started, I'll be creating a new github project. I'd like to name the project "Resteasy Skeleton Key" or "Picketlink Skeleton Key". Thoughts? Concerns? Ideas? Insults? Whines? Cheers? Trash Talk? Once things get moving we'll also be talking to PM and the Cloud BU. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org) https://lists.jboss.org/mailman/listinfo/security-dev