+1
On Thu, Mar 6, 2014 at 8:22 AM, Kevin Minder
wrote:
> Hi Everyone,
> I would like to propose starting the release process for a 0.4.0 release.
> There have been a number of new features added recently. In addition I
> would like to have a TLP release. Thoughts?
> Kevin.
>
> --
> CONFIDENTIA
Hi Everyone -
I have added a new rendering of the 0.4.0 site Users Guide in anticipation
of the 0.4.0 release. If you could take a look and let me know what you
think of it compared to the old one that would be appreciated.
I currently requires a sed script to be run over the old result so that i
NOTE: you may have to manually refresh the page to pull the new CSS.
If you don't see a navigation menu as a sidebar on the left then refresh.
On Mon, Mar 24, 2014 at 12:05 PM, larry mccay wrote:
> Hi Everyone -
>
> I have added a new rendering of the 0.4.0 site Users Guide i
Hi Folks -
I've updated our site's home page to have a bit more descriptive content -
take a look when you have a chance.
http://knox.apache.org
thanks,
--larry
As it is Apache Licensed - it can be used anywhere freely.
:)
On Mon, Apr 14, 2014 at 4:09 PM, Pam Wonson wrote:
> That's great can I use it for the overview section :)
>
> Sent from my iPhone
>
> On Apr 14, 2014, at 12:32 PM, larry mccay wrote:
>
> > Hi Fol
The KEYS file can be found at the following location:
https://dist.apache.org/repos/dist/release/knox/KEYS
Please use that to verify the signature of the release.
On Mon, Apr 14, 2014 at 10:41 PM, Kevin Minder wrote:
> A candidate for the Apache Knox 0.4.0 release is available at:
>
> https://
nd hashes.
> 2) Built from source and ran unit tests.
> 3) Verified .zip install using WebHdfs, WebHCat, Ooize, HBase and Hive
> groovy scripts against HDP Sandbox 2.1.
>
>
> On 4/15/14 10:00 AM, larry mccay wrote:
>
>> The KEYS file can be found at the following locati
Waho!!!
On Mon, Apr 21, 2014 at 2:45 PM, Kevin Minder
wrote:
> Infra has fixed this and the 0.4.0 bits are showing up on mirrors.
> For example:
> http://apache.cs.utah.edu/knox/
>
>
>
> On 4/21/14 9:22 AM, Kevin Minder wrote:
>
>> I wasn't sure if releases in
>> https://dist.apache.org/repo
The Apache Knox team is proud to announce the release of Apache Knox
0.4.0 - our first release as an Apache TLP!
Apache Knox is a REST API Gateway for providing secure access to the data
and processing resources of Hadoop clusters. More details on Apache Knox
can be found at: http://knox.apache.or
All -
At this point, the external REST client to the KNOX Hadoop APIs have served
external clients that are outside the Hadoop perimeter quite well.
As we move from beyond being a solution for perimeter protection of
external client access to Hadoop, we have to consider the clients that
would lik
Interesting thread on common and HDFS lists. Seems it won't likely make it
into webhdfs but it is an interesting usecase for Knox...
-- Forwarded message --
From: "Nikita Makeev"
Date: Apr 24, 2014 1:09 PM
Subject: Text cmd in webhdfs
To:
Cc:
> In my company we're using webhdfs
s.
I will be adding documentation to the users guide for this functionality
and fully expect some of the clunkier parts of this to evolve in the near
time.
thanks,
--larry
On Fri, Apr 25, 2014 at 5:14 PM, larry mccay wrote:
> All -
>
> At this point, the external REST client to the K
Hello Marton -
Thank you for posting to the dev list!
Kevin has been on the road this week and I believe today is a travel day -
so he will likely be unavailable most of the day.
I think that your thinking is mostly inline with what we have considered
while investigating OAuth support for Knox i
All -
The discussion on jira:
https://issues.apache.org/jira/browse/HIVE-7010leads me to believe
that we will need to deal with multiple API versions
via component release versions - as Kevin has spoken of as well.
Templeton is removing the .../v1/queue APIs and adding a .../v1/job APIs.
The way
still be reving their version number. For example
> .../v1/queue
> .../v2/job
> Not that we have any say in the matter.
>
>
> On 5/5/14 3:14 PM, larry mccay wrote:
>
>> All -
>>
>> The discussion on jira:
>> https://issues.apache.org/jira/browse/HIVE-70
is could be confusing to the end client.
>
> Thanks
> Dilli
>
>
>
> On Mon, May 5, 2014 at 1:46 PM, larry mccay wrote:
>
> > They are willing to revert and he followed up with an approach that
> matches
> > what my expectations would have been. Which woul
are using. If Knox made that decision for them they would
> > have no way to tell. Granted you can make the argument that it should
> > always be backwards compatible. However if this were the case there
> > wouldn't really have been a need to rev the API version.
> >
tch.
>
> Our reason to have an OAuth2 provider is to offer the same experience -
> when customers interact with the cluster secured via Knox our use our UI
> they don’t need to maintain different set of credentials or re-sign when
> switching between the web applications.
>
> Mar
e can work on getting
it plugged into Knox.
I think there is great potential there and would love to see this move
forward.
What do you think?
thanks,
--larry
On Tue, May 6, 2014 at 11:13 AM, larry mccay wrote:
> Hi Marton -
>
> Thank you for the additional context - it does mak
Let's try from this email address
-- Forwarded message --
From: Larry McCay
Date: Fri, May 16, 2014 at 3:18 PM
Subject: Fwd: Reg HttpFS
To: larry mccay
-- Forwarded message --
From: Larry McCay
Date: Fri, May 16, 2014 at 3:06 PM
Subject: Fwd: Reg H
Here is a good article on using Oltu in JAX-RS to authenticate a google
user and acquire user profile information:
http://carminedimascio.com/2014/02/google-oauth2-and-jax-rs/
Note the use of JWT as well.
for this request here:
> https://github.com/ekohlwey/knox/tree/KNOX-250
> And I've also included some thoughts on the issue under its JIRA ticket:
> https://issues.apache.org/jira/browse/KNOX-250
>
> Any feedback is much appreciated!
>
>
> On Mon, Feb 10, 2014 at 11:55
JWT from the OAuth reponse?
> |
> String idToken= oAuthResponse.getParam(||"id_token"||);
>
> |Is the content of idToken the same exact value that would be presented in
> the Authorization header of the subsequent request?
>
>
> On 5/17/14 3:43 PM, larry mccay wrote:
>
e the relevant switches
- like grant_type sort of things is all we will need to morph from one to
another?
On Mon, May 19, 2014 at 9:11 AM, larry mccay wrote:
> Yeah, those details aren't clear - sort of what happens when you describe
> using a solution rather than the spec, I think.
> Th
rg/jira/browse/KNOX-385
> > Project: Apache Knox
> > Issue Type: Bug
> > Components: Server
> >Reporter: Larry McCay
> >Assignee: Larry McCay
> > Fix For: 0.5.0
> >
> >
> > C
All -
As I begin to add the beginnings of the management API to Knox, it occurs
to me that certain resource URLs will require/allow anonymous access.
For instance, admin/api/v1/version shouldn't require authentication - since
it may be used to determine which contract to use or some other non-req
nsufficient. This is because of the way we hand
> off to Jersey. It doesn't matter which chain you come in through as long
> as you have declared the correct packages. This assumption would need to
> be verified though.
>
>
> On 6/20/14 6:14 PM, larry mccay wrote:
>
>
ous pattern/chain.
>
>
> On 6/20/14 6:59 PM, larry mccay wrote:
>
>> That is exactly what I am describing.
>>
>> I'll have to dig into the jersey handoff in order to understand though I
>> think you are saying that the patterns aren't used to route to any
>
All -
I have been thinking about how to go about introducing branches for POCs or
features that are not quite ready for prime time.
Kevin and I have discussed it a bit offline and have a high level proposal
for it.
We can create feature branches that are named after jira that represent the
featu
Hi Ed -
The issue is more accurately described as the wrong method because
contributeProvider is really part of the process of building the topology
webapp not part of the webapp itself. Therefore, anything done inside of
those methods are only invoked when a new version of the topology file is
cr
When I was looking at adding the hadoop auth provider, I found that all the
topologies in the existing tests were missing the name element to specify
the shiro provider. That is likely what this issue is.
I still have my change - I'll try and get a patch that you can try.
Please apply it and run t
Okay, Dilli - I reopened the issue and provided a patch for the tests that
I had to change previously.
Hopefully, when you apply and run the tests it will resolve all of the
issues.
On Mon, Jul 28, 2014 at 10:30 AM, larry mccay wrote:
> When I was looking at adding the hadoop auth provider
Terrific!
On Mon, Jul 28, 2014 at 2:08 PM, Ed Kohlwey wrote:
> Makes sense to me - I'll incorporate these changes into my approach.
> Thanks!
>
>
> On Thu, Jul 24, 2014 at 11:58 AM, larry mccay
> wrote:
>
> > Hi Ed -
> >
> > The issue is more accu
Folks -
I think it is time that we begin talking about the next release for Apache
Knox.
There are quite a few fixed and outstanding jiras that would be candidates
for this release.
We will need to determine a couple things:
1. Version numbering for the release. I believe that we have a couple
ly our package structure to
> org.apache.knox. I had always considered this a step we would take as part
> of a 1.0 release.
>
>
> On 8/5/14 12:24 PM, larry mccay wrote:
>
>> Folks -
>>
>> I think it is time that we begin talking about the next release for Apache
; name change?
>
>
> On 8/5/14 1:58 PM, larry mccay wrote:
>
>> Yes - that is a good point and should be done regardless of version
>> designation but certainly if we are to go with a 1.0.
>>
>>
>> On Tue, Aug 5, 2014 at 12:37 PM, Kevin Minder <
>> kev
Folks -
I feel as though we should uptake the policy that is used for Hadoop common
commits where every commit includes a record of the change in CHANGES.txt.
This will make the release process easier since we won't have to backfill
all of the changes at release candidate creation time.
Also, as
olved with that.
Thoughts?
--larry
On Tue, Aug 5, 2014 at 2:07 PM, larry mccay wrote:
> Seems like they should be done at the same time to me.
> Is there some reason that they should be separated in terms of risk of
> completion or something else?
>
>
>
> On Tue, Aug 5, 20
a bit short on time to
> integrate it back into the master branch and make some updates that Larry
> has suggested, but hopefully I can in the coming week or two.
>
>
> On Wed, Aug 6, 2014 at 2:44 PM, larry mccay wrote:
>
>> Folks -
>>
>> I'd like to summarize a bri
will make for a
great offering and we need to plan in order to bring them in smoothly.
thanks,
--larry
On Thu, Aug 7, 2014 at 12:55 PM, larry mccay wrote:
> We can certainly consider that, Ed!
> The plan is to branch for the 0.5.0 release around the end of the month.
> If we can get
All,
We will be branching for 0.5.0 at the end of today (9/2) if there are no
objections.
Once that is done, all changes for 0.5.0 will need to be made first on
master and then picked into the 0.5.0 branch.
Let me know if you have any questions or concerns about this.
--larry
All -
In order to describe the installation of a production deployment vs a demo
deployment, I would like to separate the out-of-the-box install from demo
setup.
Currently, when you unpack the knox archive, the conf directory includes a
couple artifacts that are demo specific and are not likely r
DP Sandbox demo)? Ideally there could be others right?
>
>
> On 9/2/14 11:11 AM, larry mccay wrote:
>
>> All -
>>
>> In order to describe the installation of a production deployment vs a demo
>> deployment, I would like to separate the out-of-the-box install from
Everyone -
We have officially branched for the 0.5.0 release and will require commits
to both master and to v0.5.0 for every change that needs to be in the 0.5.0
release.
An easy way to do this is by committing to master then cherry-picking back
to 0.5.0.
You will notice that master now builds a
All -
Pascal Oliva has filed KNOX-242 and provided a patch contribution for
replacing the use of the sun/oracle proprietary classes with the use of the
Bouncy Castle library.
With reported plans from oracle to limit or block access to the old sun
classes it seems that we need to make a move here
gt;
> On Mon, Sep 15, 2014 at 2:06 PM, larry mccay
> wrote:
>
> > All -
> >
> > Pascal Oliva has filed KNOX-242 and provided a patch contribution for
> > replacing the use of the sun/oracle proprietary classes with the use of
> the
> > Bouncy Castle library.
some scripting around that for standing up a
test/demo environment easily.
On Mon, Sep 15, 2014 at 5:19 PM, larry mccay wrote:
> I've considered this, Vinay.
>
> I'm not sure the value of providing a sun based implementation given that
> the classes are going away and that the im
tance without any tools for changing the
keystores or master password etc.
On Mon, Sep 15, 2014 at 5:43 PM, larry mccay wrote:
> Another alternative would be to remove the auto generation of a
> self-signed cert from the server runtime and require the use of the admin's
> favorite key
+1
On Tue, Sep 16, 2014 at 10:38 PM, Kevin Minder wrote:
> Hi Everyone,
>
> I've made the change in master to switch the groupId in all of the pom.xml
> files from org.apache.hadoop to org.apache.knox.
> See https://issues.apache.org/jira/browse/KNOX-424
>
> The question is should I cherry-pick
All -
A candidate for the Apache Knox 0.5.0 release is available at:
https://dist.apache.org/repos/dist/dev/knox/knox-0.5.0/
The release candidate is a zip archive of the sources in:
https://git-wip-us.apache.org/repos/asf/knox.git
Branch v0.5.0 (git checkout -b v0.5.0)
The SHA1 checksum of th
If this is a blocker for 0.5.0 then we should cancel the current vote for
0.5.0 rc0.
On Wed, Sep 24, 2014 at 10:02 AM, Sumit Gupta (JIRA)
wrote:
>
> [
> https://issues.apache.org/jira/browse/KNOX-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146
ier bits
>> and not these. I’ll do some verification and recast my vote.
>>
>> Sumit.
>>
>> On Sep 23, 2014, at 2:52 PM, Sumit Gupta
>> wrote:
>>
>> +1
>>>
>>> On Sep 23, 2014, at 2:00 PM, larry mccay wrote:
>>>
>>
=14153243#comment-14153243
> ]
>
> pascal oliva commented on KNOX-422:
> -------
>
> Larry McCay, did you run the tests in your side with KNOX-422-2.patch ?
>
> > Build break with JVM IBM JAVA
> > -
> >
All -
As a heads up, I will be assembling a release candidate for a v0.5.0
release this weekend and potentially into Monday.
I believe that the blocker issues have been resolved as well as a number of
other minor fixes that cropped up in between the last rc and the current
state.
I will be updat
All -
As a heads up, I will be assembling a release candidate for a v0.5.0
release this weekend and potentially into Monday.
I believe that the blocker issues have been resolved as well as a number of
other minor fixes that cropped up in between the last rc and the current
state.
I will be updat
All -
As a heads up, I will be assembling a release candidate for a v0.5.0
release this weekend and potentially into Monday.
I believe that the blocker issues have been resolved as well as a number of
other minor fixes that cropped up in between the last rc and the current
state.
I will be updat
All -
A new candidate for the Apache Knox 0.5.0 release is available at:
https://dist.apache.org/repos/dist/dev/knox/knox-0.5.0/
The release candidate is a zip archive of the sources in:
https://git-wip-us.apache.org/repos/asf/knox.git
Branch v0.5.0 (git checkout -b v0.5.0)
The SHA1 checksum of
gt; Verified MD5, SHA.
>> Built and ran unit tests successfully.
>>
>> +1 Release this package as Apache Knox 0.5.0
>>
>> On Sun, Oct 26, 2014 at 12:48 PM, larry mccay wrote:
>>
>> All -
>>>
>>> A new candidate for the Apache Knox 0.5.0 release i
All -
I am pleased to announce that the vote for release v0.5.0 has successfully
passed with:
3 binding +1's
1 non-binding +1
0 -1's
I will be tagging and promoting the release momentarily.
Congrats and thank you for your testing!
--larry
On Mon, Nov 3, 2014 at 7:52 PM, larry mc
The Apache Knox community is proud to announce the availability of our
0.5.0 release! A significant amount of work has gone into this release with
80+ bug fixes, improvements and a number of important new features.
One of the most notable features of this release is the HDFS HA support.
This enabl
All -
Now that we have delivered our 0.5.0 release, we need to consider our next
couple releases.
We should first consider preparing for an 0.5.1 release to accommodate any
issues that crop up with the latest available release.
I propose (1): creating a branch within the next day or so. This wil
testing from gmail account.
Resending this from my gmail account - since my apache account doesn't seem
to be working at the moment
Note that this was sent over the weekend - so we will be trying to cut an
rc sometime *this* week.
On Sat, Nov 22, 2014 at 11:38 AM, larry mccay wrote:
> All -
>
> I create
ld mean getting 0.6.0 out sooner rather than an 0.5.2. Now of course if
> we find some non-feature critical fixes that we want to bundle into an
> 0.5.2 that could make sense but not based on any cadence.
>
>
>
> On 11/7/14 12:17 PM, larry mccay wrote:
>
>> All -
>>
test
A candidate for the Apache Knox 0.5.1 release is available at:
https://dist.apache.org/repos/dist/dev/knox/knox-0.5.1/
The release candidate is a zip archive of the sources in:
https://git-wip-us.apache.org/repos/asf/knox.git
Branch v0.5.1 (git checkout -b v{gateway-version})
The KEYS file for
All -
The Project Management Committee (PMC) for Apache Knox
has asked Sumit Gupta to become a committer and PMC member
and we are pleased to announce that they have accepted.
Sumit added significantly to the 0.5.0 Apache Knox release by contributing
both bug fixes and full features to the releas
fixed
+1 binding
On Fri, Dec 5, 2014 at 8:44 AM, larry mccay wrote:
> A candidate for the Apache Knox 0.5.1 release is available at:
>
> https://dist.apache.org/repos/dist/dev/knox/knox-0.5.1/
>
> The release candidate is a zip archive of the sources in:
>
> https://git-wip-us
Thanks, Sumit - I agree on all points - jira id as name is fine - I don't
know that we need to be strict about that point but it is a good general
guide.
+1
On Mon, Dec 29, 2014 at 3:20 PM, Sumit Gupta
wrote:
>
> I would like to seek opinions on using Git branches (remote branches) for
> featur
nit tests.
>>
>> +1 binding
>>
>> On Dec 8, 2014, at 7:32 PM, larry mccay wrote:
>>
>> I have downloaded the release candidate and:
>>>
>>> * checked the CHANGES file
>>> * verified the signature and hashes
>>> * buil
The vote for releasing 0.5.1 received the following votes:
+1 (binding):
Kevin Minder
Sumit Gupta
Larry McCay
+1 (non-binding):
none
-1:
none
With 3 positive binding votes and no negative votes - the release vote
passes.
Thanks to everyone for making this release happen!
--larry
On Sun, Jan
The Apache Knox team is proud to announce the release of Apache Knox 0.5.1!
Apache Knox is a REST API Gateway for providing secure access to the data
and processing resources of Hadoop clusters. More details on Apache Knox
can be found at: http://knox.apache.org/
The release bits are available at
Thanks!
On Tue, Jan 20, 2015 at 11:40 PM, Kevin Minder wrote:
> Hi Everyone,
> I wanted to quickly capture my notes on publishing to the Apache Maven
> repo. I dumped this into the release process wiki too. I did this for
> 0.5.1 so this should be the last step of getting that out.
>
> Get you
Good catch! Please do provide a patch.
Thank you for your contributions!
On Jan 21, 2015 7:58 AM, "J.Andreina (JIRA)" wrote:
>
> [
> https://issues.apache.org/jira/browse/KNOX-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14285591#comment-14285591
This sounds like an excellent step forward for the deployment machinery of
Knox - good work!
It will also provide even greater compatibility with Hadoop platform
deployments.
We should continue this work to define collections of versioned services as
a single Hadoop platform definition - composite
ed and may just be easy enough
> >to look at in your IDE.
> >
> >Sumit.
> >
> >
> >
> >On 2/17/15, 10:55 PM, "larry mccay" wrote:
> >
> >>This sounds like an excellent step forward for the deployment machinery
> >>
Hi Dimple -
I don't recall hearing of anyone with an issue like this - I think that in
order to help you that I will need a bit more information:
1. What are the APIs that you have going through Knox and routing service
are you using to do this with?
2. Knox doesn't typically do redirection to we
All -
We have a number of interesting features in master that enhance the
developer's ability to extend Apache Knox with new routing services, new
identity assertion providers, etc.
We have also accumulated a number of bug fixes from the community that are
greatly appreciated.
I think that we ne
> either case, I can always double merge/cherry pick, so no big deal. Let¹s
> branch.
>
> Sumit.
>
> On 3/22/15, 11:27 AM, "larry mccay" wrote:
>
> >All -
> >
> >We have a number of interesting features in master that enhance the
> >developer
Hi Kevin -
Sounds good!
Thanks for taking the release manager role for 0.6.0.
I would like to get KNOX-509 in before branch if possible.
I'll try and get it in before Friday.
thanks!
--larry
On Wed, Apr 8, 2015 at 7:07 PM, Kevin Minder
wrote:
> Hi Everyone,
> I believe that there have been
All -
After committing the changes for KNOX-509 - KnoxSSO - we have a minimum jdk
requirement of 1.7.
The apache jenkins job failed due to the dependency from the nimbus jwt
library on 1.7.
I changed the jenkins configuration and rebuilt and it is stable again.
Apparently Hadoop common is runni
I have:
* Verified signatures
* built from source and ran unit tests
* checked LICENSE, NOTICE, ISSUES, README
* run through samples
* exercised webhdfs and webhcat/templeton manually
* tested hostmapping
* tested 2-way ssl mode
* tested Concat identity assertion provider
* tested KnoxSSO endpoint
All -
I think we need to determine the best way forward for our trusted proxy
support.
Today, we have the details of the various ?doAs= vs ?username= parameters
in the identity assertion httpServletRequestWrapper.
Some services are coming into the fold with new or just plain different
query para
ut of the way by allowing a service to declare all the errors that it
> would like to failover on and all the errors to retry on. Pinging servers
> and finding the next available is another storyŠ
>
> Sumit.
>
>
> On 5/11/15, 7:08 PM, "larry mccay" wrote:
>
&
Nice!
I look forward to seeing this!
On Tue, Jul 14, 2015 at 3:47 PM, Kevin Minder
wrote:
> Excellent. I look forward to this valuable contribution to Knox.
>
>
>
>
> On 7/14/15, 3:41 PM, "Jeffrey Rodriguez" wrote:
>
> >I have implemented PAM authentication based on shiro-libpam4j and it is
>
gt; > NPE for Topology with no Providers Confgured
> >
> >
> > Key: KNOX-564
> > URL: https://issues.apache.org/jira/browse/KNOX-564
> > Project: Apache Knox
> > Issue Type: Bug
> >Reporter: Larry
All -
I see that KNOX-584 was filed by Zac to address this but I wanted to make
sure that everyone is aware that we have some instability in the jenkins
builds.
See: https://builds.apache.org/job/Knox-master-verify/701/
We have 3 failures there:
1. in CLIServiceTest - covered by KNOX-584:
Error
+1 :)
On Wed, Aug 12, 2015 at 12:16 PM, Sumit Gupta
wrote:
> Agreed on XForwardHeaders related tests. I can take those on and I will
> file a JIRA to track it.
>
> Thanks Zac for taking the CLIServiceTest failure.
>
> Sumit.
>
> On 8/12/15, 12:11 PM, "larry mccay
This strategy sounds great to me.
Abstracting the config object makes sense as well - even if just making it
a factoryContext type of thing would be better.
I'm not sure that we need gateway level configurability though a default in
the service definition would be good.
Perhaps, the ability to ove
All -
I am considering the option of removing the topology "service" name from
the API resource path.
The current implementation is aligned with all existing patterns for
service integrations but seems to pose a more difficult time in naming the
topology than it should.
Considering that the curr
for REST clients - like OAuth.
One will set a cookie as a result the other return JSON with a token to use
as bearer token and metadata about the token.
>
>
>
>
>
> On 11/2/15, 1:34 PM, "larry mccay" wrote:
>
> >All -
> >
> >I am considering the
the service is part of
> the
> >resource path can be debated.
> >
> >
> >>
> >> And if the resource really does token exchange why not
> >> https://localhost:8443/gateway/auth-ui/knoxsso/api/v1/token-exchange
> >> https://localhost:8443/gateway/
- thoughts?
On Tue, Nov 3, 2015 at 9:49 AM, larry mccay wrote:
> Agreed.
>
> I'm not sure that you would name your topology that way if you intended to
> use it for REST though.
> We could certainly create credential collectors in the client shell that
> interacted with a
ovider chains per service.
Conversely, if we added a new directory in conf/topologies for
conf/topologies/gateway then we could aggregate them all under services but
provision their own provider chains.
On Tue, Nov 3, 2015 at 11:47 AM, Kevin Minder
wrote:
> Inline...
>
>
>
> On
.
On Tue, Nov 3, 2015 at 2:00 PM, larry mccay wrote:
> Good point...
>
> So, we couldn't have admin and knoxsso APIs in the same topology.
> We could have other fully qualified services/URLs in the same topology
> though - like WEBHDFS.
>
> This starts to feel like
a
>> >real example, it's easier to start with it.
>> >
>> >Thanks for your answers.
>> >
>> >Like Shiro, pac4j has LDAP support and caching can be done. The only
>> >difference is that pac4j relies on ldaptive (http://www.ldapt
ederation and see if that helps.
On Tue, Nov 10, 2015 at 11:21 AM, larry mccay wrote:
> Hi Jérôme -
>
> Happy to see you here!
> I apologize for having missed your note on the list a few days ago.
>
> Glad to see that the article was helpful and it seems like you are making
>
Works for me.
On Tue, Nov 10, 2015 at 1:46 PM, Kevin Minder
wrote:
> Some of you might not be aware that we have an github mirror at
> https://github.com/apache/knox
>
> So far we have’t really done much with it but I see that other Apache
> projects use their mirrors more extensively. That may
t;
>
>
>
>
> 2015-11-10 17:36 GMT+01:00 Kevin Minder :
>
> > To be a bit more explicit your Pac4jFederationProviderContributor
> declares
> > itself to be of role “federation” but when you used it in the sandbox.xml
> > topology file you were attempt
final packaged server. If you
> take a look at that you will see it references all of the providers that
> are intended to be included by default. Try adding yours to the
> dependencies.
>
>
>
>
> On 11/12/15, 7:49 AM, "larry mccay" wrote:
>
> >We rea
1 - 100 of 3992 matches
Mail list logo
