Member since
09-24-2015
49
Posts
67
Kudos Received
16
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
5284 | 03-29-2016 03:02 PM | |
2982 | 03-21-2016 01:34 PM | |
3446 | 03-07-2016 09:12 PM | |
2892 | 01-12-2016 10:01 PM | |
1063 | 01-11-2016 10:04 PM |
10-27-2015
05:00 PM
2 Kudos
To add to @Alex Miller's answer here is the doc section for creating the password alias. http://knox.apache.org/books/knox-0-6-0/user-guide.html#Alias+creation
... View more
10-23-2015
01:54 PM
Specifically Knox supports TAM now ISAM via pre-authenticated headers. You can find out more here: http://knox.apache.org/books/knox-0-6-0/user-guide.html#Preauthenticated+SSO+Provider
... View more
10-22-2015
04:29 PM
Keep in mind that you can broaden the scope of the search by making the value of main.ldapRealm.userSearchBase to possible help with part 2 of the question. However, you need to be careful for two reasons: Performance - The larger the base of the search the more entries that must be searched for the matching userSearchAttributeName. Query Limits - In some LDAP implementation there are limits to how may entires a given query can return so too broad a userSearchBase may result in a failed queries causing authentication failures.
... View more
10-22-2015
04:20 PM
3 Kudos
Knox is a proxy and as such does add overhead. At a simplistic level, this overhead can be broken down into five areas: Authentication and authorization - The additional time required to perform authentication and authorization. Connection creation - The additional time required to setup the connection between Knox and the backend service. Data transport - The additional time required physically move the request and response data through the Knox server unaltered. Request and response processing - The additional time imposed by processing done to the request and response data stream. SSL termination - The additional time imposed by SSL encryption if the direct connection to the service would otherwise not occur over a secure connection. We try to set expectations at around +0.5 to +1.0 in terms of overhead, yielding a 1.5x to 2.0x increase in overall response times. These types of numbers are of course highly generalized and may vary significantly based on the use case. For example, as you point for very small requests and responses the connection creation time may disproportionately dominate overall and produce a higher relative overhead.
... View more
10-09-2015
03:40 PM
1 Kudo
However, the way you need to be thinking about this is to rewrite the URL in the outbound response in which it is contained. This is certainly more complex but you can find some examples of how to do this in the HBase integration in data/services/hbase/0.98.0. It involves the use of filters on the outbound response bodies.
... View more
10-09-2015
03:34 PM
1 Kudo
Unfortunately that isn't going to work, at least not the way you are thinking about it. There are a few reasons for this. The first is that each topology file is deployed within the server "under the covers" as a JEE WAR. In particular it is deployed on a context path made up of the value of gateway.path in gateway-site.xml and the name of the topology file. So all of the URLs will start with {gateway.path}/{topology} no matter what. Beyond that each service or app generally then carves out a unique subcontext to avoid collisions.
... View more
10-09-2015
01:46 PM
1 Kudo
Look for example at this HBase rule which does something similar to what I believe you are asking. This rule however will handle anything under **/hbase due to the ** in {path=**}. <rule dir="IN" name="WEBHBASE/webhbase/path/inbound" pattern="*://*:*/**/hbase/{path=**}?{**}">
<rewrite template="{$serviceUrl[WEBHBASE]}/{path=**}?{**}"/>
</rule> You can certainly also write a pattern for a single file. I assume here that your service's role is MYSERVICE which is why it is upper case in the $serviceUrl[MYSERVICE] function. That could hypothetically look something like this: <rule dir="IN" name="MYSERVICE/myservice/logo" pattern="*://*:*/**/myservice/myLogo.png?{**}">
<rewrite template="{$serviceUrl[MYSERVICE]}/myLogo.png?{**}"/>
</rule> I wasn't sure about including the ?{**} in the rewrite template to propagate the query parameters but it is a good idea to include it in the match pattern to make it as general as possible. If you didn't include the ?{**} in the rewrite template the query parameters would not be copied over from the original matched URL. Either behavior may be what you want.
... View more
10-05-2015
03:09 PM
2 Kudos
Currently Knox uses the username returned by the authentication provider. This identity can then be manipulated by an identity-assertion provider. However at this time none of the "out of the box" identity-assertion providers support an ability to lower case the identity. This would however be very easy to implement and plug in "on site". It would require implementing a custom identity-assertion provider that essentially implements the mapUserPrincial method of org.apache.hadoop.gateway.identityasserter.common.filter.AbstractIdentityAssertionFilter in module gateway-provider-identity-assertion-common. The whole process of writing and hooking up a Knox extension plugin is described in Larry's blog.
http://hortonworks.com/blog/adding-federation-provider-apache-knox/ This described a federation provider but the overall mechanism is similar. General details about Knox development can be found in the dev guide.
http://knox.apache.org/books/knox-0-6-0/dev-guide.html
... View more
09-29-2015
02:18 PM
2 Kudos
In the Knox <knox-home>/bin/gateway.sh file (e.g. /usr/hdp/current/knox-server/bin/gateway.sh) you will find a variable that can be populated with JVM memory settings. APP_MEM_OPTS="" For example, you could provide the values show below for an initial and max 2GB heap. Knox will need to be restarted for this to take effect. APP_MEM_OPTS="-Xms2g -Xmx2g"
... View more
09-29-2015
02:08 PM
1 Kudo
Labels:
- Labels:
-
Apache Knox
- « Previous
- Next »