Hi Christopher -

I apologize, this dropped off my radar.
I need to go back and try and reproduce it still.

It would still be surprising to me but I am surprised often. :)

thanks,

--larry

On Thu, Jul 12, 2018 at 5:29 PM, Christopher Jackson <
jackson.christopher....@gmail.com> wrote:

> Hey Larry,
>
> I looked into this a bit deeper. It appears the knoxsso-topology is NOT
> updated because of the following code in /var/lib/ambari-server/
> resources/common-services/KNOX/0.5.0.2.2/package/scripts/knox.py:
>
>   if params.version_formatted and check_stack_feature(
> StackFeature.KNOX_SSO_TOPOLOGY, params.version_formatted):
>       File(os.path.join(params.knox_conf_dir, "topologies",
> "knoxsso.xml"),
>          group=params.knox_group,
>          owner=params.knox_user,
>          content=InlineTemplate(params.knoxsso_topology_template)
>       )
>
> I believe the if condition is evaluating to false and thus preventing the
> knoxsso.xml from being written as I do not see a corresponding output entry
> in the log of a restart of the Knox Service (IE. I would expect to see a
> File['/usr/hdp/current/knox-server/conf/topologies/knoxsso.xml’] line):
>
> 2018-07-12 12:42:43,870 - Generating config: 
> /usr/hdp/current/knox-server/conf/gateway-site.xml
> 2018-07-12 12:42:43,871 - 
> File['/usr/hdp/current/knox-server/conf/gateway-site.xml'] {'owner': 'knox', 
> 'content': InlineTemplate(...), 'group': 'knox', 'mode': None, 'encoding': 
> 'UTF-8'}
> 2018-07-12 12:42:43,879 - 
> File['/usr/hdp/current/knox-server/conf/gateway-log4j.properties'] 
> {'content': InlineTemplate(...), 'owner': 'knox', 'group': 'knox', 'mode': 
> 0644}
> 2018-07-12 12:42:43,887 - 
> File['/usr/hdp/current/knox-server/conf/topologies/default.xml'] {'content': 
> InlineTemplate(...), 'owner': 'knox', 'group': 'knox'}
> 2018-07-12 12:42:43,890 - 
> File['/usr/hdp/current/knox-server/conf/topologies/admin.xml'] {'content': 
> InlineTemplate(...), 'owner': 'knox', 'group': 'knox'}
> 2018-07-12 12:42:43,891 - 
> Execute['/usr/hdp/current/knox-server/bin/knoxcli.sh create-master --master 
> [PROTECTED]'] {'environment': {'JAVA_HOME': u'/usr/jdk64/jdk1.8.0_112'}, 
> 'not_if': "ambari-sudo.sh su knox -l -s /bin/bash -c 'test -f 
> /usr/hdp/current/knox-server/data/security/master'", 'user': 'knox'}
>
>
> This is on HDP 2.6.2 using Knox 0.12.0. I’ve created issue
> https://issues.apache.org/jira/browse/AMBARI-24285 to track.
>
> Regards,
> Christopher Jackson
>
>
>
> On Jun 27, 2018, at 7:13 PM, larry mccay <lmc...@apache.org> wrote:
>
> Interesting, I will need to try and reproduce this but it is definitely
> the first that I have heard of it.
>
> On Wed, Jun 27, 2018 at 6:36 PM, Christopher Jackson <
> jackson.christopher....@gmail.com> wrote:
>
>> Hi Larry,
>>
>> 4) On HDP 2.6.2 I have noticed that when I make changes to the "Advanced
>> knoxsso-topology” section for the Knox Service in Ambari and then restart
>> the service that the changes are not persisted to disk at
>> /usr/hdp/current/knox-server/conf/topologies/knoxsso.xml and thus the
>> changes are not picked up until that file is hand edited to reflect the
>> changes. Is this a known issue? For example changes to the
>> “knoxsso.redirect.whitelist.regex” in the ambari config will not take
>> effect until the file mentioned above is hand edited.
>>
>> The trick is that you have to restart the server in order for Ambari to
>> actually push any config changes out to the Knox instances.
>> This is unfortunate - since Knox can hot deploy topology changes but is
>> what it is.
>> Be aware that if you hand edit the files as you are, the next time you
>> restart via Ambari it will overwrite any changes that you have made there.
>>
>>
>>
>> To be clear. I am restarting the knox service via the ambari UI after I
>> make the changes to the knox configuration in the ambari UI. After restart
>> I am seeing that the above file is NOT updated, hence why I am forced to
>> modify it by hand.
>>
>> Changes made to “Advanced topology” are correctly written to disk after
>> an update to the config and a subsequent restart of the knox service. It
>> seems to just be the “Advanced knoxsso-topology” that has the issue.
>>
>> Regards,
>>
>> Christopher Jackson
>>
>>
>>
>> On Jun 27, 2018, at 1:11 PM, larry mccay <lmc...@apache.org> wrote:
>>
>> Hi Christopher -
>>
>> 1) Is it possible to include additional claims that contain group
>> information for the user from LDAP?
>>
>> Not currently - there are a couple issues with this appproach but I
>> wouldn't be against a patch that optionally enables it.
>> * There can be 100's of groups sometimes for a given user
>> * No one in the current ecosystem is expecting to extract groups from the
>> cookie for authorization purposes and group lookup is done closer to the
>> resource itself
>> * Given that the token represents an authentication event as a snapshot
>> in time, the group membership may change by the time you extract them from
>> the token
>>
>> 2) Does the Knox SSO implementation support JSON Web Key (JWK)?
>>
>> Not currently.
>>
>> 3) Where is the signing key stored? I have the desire to validate the JWT
>> in a third party web container. I am using Knox 0.12.0 on HDP 2.6.2.
>>
>> By default it uses the gateway-identity alias within the
>> {GATEWAY_HOME}/data/security/keystores/gateway.jks keystore.
>> It may also be configured to use custom signing keys [1] - via
>> gateway.signing.keystore.name and gateway.signing.key.alias
>>
>> 4) On HDP 2.6.2 I have noticed that when I make changes to the "Advanced
>> knoxsso-topology” section for the Knox Service in Ambari and then restart
>> the service that the changes are not persisted to disk at
>> /usr/hdp/current/knox-server/conf/topologies/knoxsso.xml and thus the
>> changes are not picked up until that file is hand edited to reflect the
>> changes. Is this a known issue? For example changes to the
>> “knoxsso.redirect.whitelist.regex” in the ambari config will not take
>> effect until the file mentioned above is hand edited.
>>
>> The trick is that you have to restart the server in order for Ambari to
>> actually push any config changes out to the Knox instances.
>> This is unfortunate - since Knox can hot deploy topology changes but is
>> what it is.
>> Be aware that if you hand edit the files as you are, the next time you
>> restart via Ambari it will overwrite any changes that you have made there.
>>
>> HTH.
>>
>> --larry
>>
>> 1. http://knox.apache.org/books/knox-1-0-0/user-guide.html#
>> Gateway+Server+Configuration
>>
>>
>> On Wed, Jun 27, 2018 at 1:00 PM, Christopher Jackson <
>> jackson.christopher....@gmail.com> wrote:
>>
>>> Hey Folks,
>>>
>>> I’ve enabled Knox SSO and I am able to navigate to the Knox SSO UI and
>>> enter credentials to log in. I am seeing that the JWT cookie is properly
>>> created with the claims that I would expect. Some questions:
>>>
>>> 1) Is it possible to include additional claims that contain group
>>> information for the user from LDAP?
>>>
>>> 2) Does the Knox SSO implementation support JSON Web Key (JWK)?
>>>
>>> 3) Where is the signing key stored? I have the desire to validate the
>>> JWT in a third party web container. I am using Knox 0.12.0 on HDP 2.6.2.
>>>
>>> 4) On HDP 2.6.2 I have noticed that when I make changes to the "Advanced
>>> knoxsso-topology” section for the Knox Service in Ambari and then restart
>>> the service that the changes are not persisted to disk at
>>> /usr/hdp/current/knox-server/conf/topologies/knoxsso.xml and thus the
>>> changes are not picked up until that file is hand edited to reflect the
>>> changes. Is this a known issue? For example changes to the “
>>> knoxsso.redirect.whitelist.regex” in the ambari config will not take
>>> effect until the file mentioned above is hand edited.
>>>
>>> Regards,
>>>
>>> Christopher Jackson
>>>
>>
>>
>>
>
>

Reply via email to