That isn't going to work actually. I am going to need to put some thought into how to detect whether it needs to be redirected in a filter that can be added by the Shiro provider. I recall running into this earlier which is why I went with the login page URL.
On Mon, Apr 4, 2016 at 12:25 AM, larry mccay <[email protected]> wrote: > 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 >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> >> >
