All - After beginning to write the instructional wiki, I've decided that the combination of KnoxSSO + Default IDP (form-based) needs a change as well.
Currently, we would need to configure the participating applications to use either the URL to the knoxauth application within the knoxsso.xml topology or to the knoxsso/websso API endpoint. This would be based on whether the new default IDP was being used or not. Initially, this seemed okay to me since it was still part of KnoxSSO topology but... This would require all participating applications to change their configuration for the KnoxSSO URL if they were to migrate to a new IDP. I think that this should be avoided. All that participating applications should have to know about is the knoxsso endpoint. The specific identity solution integration should only be the concern of the KnoxSSO admin. I'm thinking that I will add a new service paramter to KnoxSSO service that will indicate that there is a colocated knoxauth application that should be redirected to if there is no cookie presented with the request. Even though the KnoxSSO service has previously relied solely on the federation providers to do whatever redirecting was required for their protocol, I am thinking that the service should be able to redirect to an application that is colocated in the topology for authentication purposes. I should be able to crank this out tomorrow and get a new rc by tomorrow night or early Tuesday. If anyone thinks that this should just be considered a known issue and that we shouldn't wait for it - just say so. thanks, --larry On Sun, Apr 3, 2016 at 11:37 PM, larry mccay <[email protected]> wrote: > Hi Sumit - > > No problem - I can cut a new rc as soon as we have a go. > Once the fix is pushed and the known issues with views is documented we > can turn the crank again. > > I will wait until at least tomorrow afternoon (eastern) for anyone else to > raise a flag. > > Thanks! > > --larry > > On Sun, Apr 3, 2016 at 10:55 PM, Sumit Gupta <[email protected]> > wrote: > >> Hi Larry, >> >> I found a small bug last week while testing the new UI proxy support for >> Ambari. This is a bug in the trunk version of ambari and does not appear >> in the 2.2.0 version. Given that we need the trunk or the latest upcoming >> release of Ambari to test the SSO work, we should get this fix in. >> >> Please also note that KNOX-705 is outstanding for the Ambari proxy UI work >> and we will need to make it a known issue for the release. >> >> Sumit. >> >> >> >> On 4/2/16, 10:26 AM, "larry mccay" <[email protected]> wrote: >> >> >All - >> > >> >I have a couple small clean up tasks to take care of and will begin to >> >clean up the 0.9.0 issue list. >> >Hope to have an rc for 0.9.0 testing by Monday or Tuesday. >> > >> >If anyone has any issues that they would like to get into 0.9.0 please >> >speak up and we can try and accommodate. >> > >> >thanks! >> > >> >--larry >> > >> >On Mon, Mar 21, 2016 at 5:36 PM, larry mccay <[email protected]> wrote: >> > >> >> All - >> >> >> >> We are ~10 days out from our target release date and have ~8 issues >> >>still >> >> open for 0.9.0. >> >> >> >> I've commented on a couple to see if we can close them or get a review >> >> done, etc. >> >> Over the next week or so, we will need to consider whether some of them >> >> need to be moved out of the 0.9.0 release. >> >> >> >> If there are any issues in bank/future that anyone feels are critical >> >>for >> >> 0.9.0 please get them in as soon as possible. >> >> >> >> thanks, >> >> >> >> --larry >> >> >> >> On Tue, Mar 8, 2016 at 1:42 PM, Sumit Gupta >> >><[email protected]> >> >> wrote: >> >> >> >>> +1 on the release timing and management. I also think that a 0.9 >> >>>before a >> >>> 1.0 would make it easier for us to work through packaging changes and >> >>>any >> >>> other "1.0" type requirements in a more isolated fashion. >> >>> >> >>> >> >>> >> >>> On 3/8/16, 9:59 AM, "larry mccay" <[email protected]> wrote: >> >>> >> >>> >I agree. >> >>> > >> >>> >Perhaps, we can target a very focused 0.10.0 -> 1.0 followup release >> >>> where >> >>> >we can clearly identify any such breakages and help with the >> migration >> >>> via >> >>> >docs or tools or whatever? >> >>> > >> >>> >On Tue, Mar 8, 2016 at 9:57 AM, Kevin Minder >> >>> ><[email protected]> >> >>> >wrote: >> >>> > >> >>> >> I'm on the fence about an 0.9 vs a 1.0. A 1.0 means fixing the >> >>>package >> >>> >> names to me mostly. Breaking backwards compatibility is always a >> >>> >>difficult >> >>> >> decision. >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> On 3/8/16, 9:55 AM, "Kevin Minder" <[email protected]> >> >>> wrote: >> >>> >> >> >>> >> >Larry, >> >>> >> >I'm +1 on the content, timing and you being RM. >> >>> >> >Kevin. >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> >On 3/8/16, 9:22 AM, "larry mccay" <[email protected]> wrote: >> >>> >> > >> >>> >> >>All - >> >>> >> >> >> >>> >> >>I'd like to volunteer to be the release manager for the 0.9.0 >> >>>release >> >>> >> >>unless someone else would like to take it instead. >> >>> >> >> >> >>> >> >>In addition, I think that we need to scope the release and >> driving >> >>> >> usecases >> >>> >> >>and a target date for the release. >> >>> >> >> >> >>> >> >>We currently have ~25 JIRAs slated for 0.9.0 and most fall into >> >>>one >> >>> or >> >>> >> more >> >>> >> >>of the following categories: >> >>> >> >> >> >>> >> >>* dependency upgrades and related fixes >> >>> >> >>* proxying of UIs for Ambari and Ranger and related issues >> >>> >> >>* the hosting of web applications >> >>> >> >>* the addition of an application for a default KnoxSSO form based >> >>> >>login >> >>> >> >>* PAM authentication provider - MISSING DOCs and TESTs >> >>> >> >>* various bug fixes and incremental improvements >> >>> >> >> >> >>> >> >>It seems that around half of these are already set to fixed. >> >>> >> >> >> >>> >> >>If there are additional issues that folks would like to get into >> >>>the >> >>> >> 0.9.0 >> >>> >> >>release then we should discuss anything that would require a >> >>>sizable >> >>> >> change >> >>> >> >>and file JIRAs for them asap. >> >>> >> >> >> >>> >> >>I believe that from the above categories that we can adjust the >> >>> >>driving >> >>> >> >>usecases from the 0.8.0 release to reflect the shift of focus >> from >> >>> >> external >> >>> >> >>applications to: >> >>> >> >> >> >>> >> >>1. SSO participation by applications like Ranger and Ambari while >> >>> >>being >> >>> >> >>proxied through the gateway. >> >>> >> >> >> >>> >> >>2. Authentication natively done by Ranger and Ambari applications >> >>> >>while >> >>> >> >>being proxied through Knox. >> >>> >> >> >> >>> >> >>3. the usecase of a custom application like the Knoxplorer sample >> >>>can >> >>> >>now >> >>> >> >>be hosted by Knox and this needs to be covered and tested with >> >>> >>KnoxSSO. >> >>> >> >> >> >>> >> >>4. Default Knox authentication with form based application as >> >>>KnoxSSO >> >>> >> IDP. >> >>> >> >> >> >>> >> >>5. any additional API support and various features and >> >>>improvements. >> >>> >> >> >> >>> >> >>It seems to me that we could start considering a 1.0 release. If >> >>>this >> >>> >> seems >> >>> >> >>like a reasonable time to do that then we should open up >> >>>discussion >> >>> >>for >> >>> >> any >> >>> >> >>additional improvements or changes that we'd want to include in >> >>>order >> >>> >>to >> >>> >> >>make it our 1.0. >> >>> >> >> >> >>> >> >>Given the above scope and driving usecases, I'd like to propose >> an >> >>> >>end of >> >>> >> >>March release. >> >>> >> >> >> >>> >> >>Thoughts? >> >>> >> >> >> >>> >> >>thanks, >> >>> >> >> >> >>> >> >>--larry >> >>> >> >> >>> >> >>> >> >> >> >> >
