[jira] [Commented] (STORM-4023) Background periodic Kerberos re-login should use same JAAS configuration as initial login
[
https://issues.apache.org/jira/browse/STORM-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810096#comment-17810096
]
Andrew Olson commented on STORM-4023:
-
I'm currently working on a patch for this.
> Background periodic Kerberos re-login should use same JAAS configuration as
> initial login
> -
>
> Key: STORM-4023
> URL: https://issues.apache.org/jira/browse/STORM-4023
> Project: Apache Storm
> Issue Type: Bug
> Components: storm-client
>Affects Versions: 2.6.0
>Reporter: Andrew Olson
>Priority: Major
> Labels: kerberos
>
> In the
> [Login|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java]
> class, a background thread is started that periodically performs a re-login
> to the Kerberos Ticket Granting Server.
> For the initial login, a custom Configuration instance is
> [created|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L257]
> and [supplied to the LoginContext
> constructor|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L300]
> potentially using a custom JAAS file location.
> However, the background refresh thread does not then subsequently provide the
> JAAS file location or Configuration to the [reLogin
> method|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L222],
> so it tries to construct a LoginContext with [just a context name and
> subject|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L409]
> but no Configuration parameter, which means that the underlying
> {{Configuration.getConfiguration()}} call has to load one from [system
> defaults|https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/jdk-11%2B28/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L242],
> which could possibly specify a different file or none at all.
> In our application where this issue was found, we had set the
> {{java.security.auth.login.config}} value to a valid JAAS file location as a
> Storm client property along with other standard connectivity properties,
> since the [Netty client
> framework|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyClient.java#L61]
> loads it [from the topology
> configuration|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/security/auth/ClientAuthUtils.java#L64].
> It looks like the Netty server framework [does the
> same|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyServer.java#L55]
> as well. The initial login succeeded and the following Storm Nimbus
> interactions were successful, but a while later it lost the ability to
> communicate with Storm with this error being logged,
> {noformat}
> ERROR [Refresh-TGT] org.apache.storm.messaging.netty.Login Could not refresh
> TGT for principal:
> javax.security.auth.login.LoginException: No LoginModules configured for
> StormClient
>at
> java.base/javax.security.auth.login.LoginContext.init(LoginContext.java:267)
>at
> java.base/javax.security.auth.login.LoginContext.(LoginContext.java:385)
>at org.apache.storm.messaging.netty.Login.reLogin(Login.java:409)
>at org.apache.storm.messaging.netty.Login$1.run(Login.java:222)
>at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> It appears that a viable workaround for this issue is to also set the system
> property,
> {{-Djava.security.auth.login.config=/some/path/jaas.conf}}
> for the application, referencing the same JAAS file location as was set in
> the Storm configuration. After doing so the background refresh thread was
> able to correctly function.
> To address this, we should be able to update the {{reLogin}} method to use
> the same JAAS configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (STORM-4023) Background periodic Kerberos re-login should use same JAAS configuration as initial login
[
https://issues.apache.org/jira/browse/STORM-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810135#comment-17810135
]
Andrew Olson commented on STORM-4023:
-
Pull request: https://github.com/apache/storm/pull/3619
> Background periodic Kerberos re-login should use same JAAS configuration as
> initial login
> -
>
> Key: STORM-4023
> URL: https://issues.apache.org/jira/browse/STORM-4023
> Project: Apache Storm
> Issue Type: Bug
> Components: storm-client
>Affects Versions: 2.6.0
>Reporter: Andrew Olson
>Priority: Major
> Labels: kerberos
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the
> [Login|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java]
> class, a background thread is started that periodically performs a re-login
> to the Kerberos Ticket Granting Server.
> For the initial login, a custom Configuration instance is
> [created|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L257]
> and [supplied to the LoginContext
> constructor|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L300]
> potentially using a custom JAAS file location.
> However, the background refresh thread does not then subsequently provide the
> JAAS file location or Configuration to the [reLogin
> method|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L222],
> so it tries to construct a LoginContext with [just a context name and
> subject|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L409]
> but no Configuration parameter, which means that the underlying
> {{Configuration.getConfiguration()}} call has to load one from [system
> defaults|https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/jdk-11%2B28/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L242],
> which could possibly specify a different file or none at all.
> In our application where this issue was found, we had set the
> {{java.security.auth.login.config}} value to a valid JAAS file location as a
> Storm client property along with other standard connectivity properties,
> since the [Netty client
> framework|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyClient.java#L61]
> loads it [from the topology
> configuration|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/security/auth/ClientAuthUtils.java#L64].
> It looks like the Netty server framework [does the
> same|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyServer.java#L55]
> as well. The initial login succeeded and the following Storm Nimbus
> interactions were successful, but a while later it lost the ability to
> communicate with Storm with this error being logged,
> {noformat}
> ERROR [Refresh-TGT] org.apache.storm.messaging.netty.Login Could not refresh
> TGT for principal:
> javax.security.auth.login.LoginException: No LoginModules configured for
> StormClient
>at
> java.base/javax.security.auth.login.LoginContext.init(LoginContext.java:267)
>at
> java.base/javax.security.auth.login.LoginContext.(LoginContext.java:385)
>at org.apache.storm.messaging.netty.Login.reLogin(Login.java:409)
>at org.apache.storm.messaging.netty.Login$1.run(Login.java:222)
>at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> It appears that a viable workaround for this issue is to also set the system
> property,
> {{-Djava.security.auth.login.config=/some/path/jaas.conf}}
> for the application, referencing the same JAAS file location as was set in
> the Storm configuration. After doing so the background refresh thread was
> able to correctly function.
> To address this, we should be able to update the {{reLogin}} method to use
> the same JAAS configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (STORM-4023) Background periodic Kerberos re-login should use same JAAS configuration as initial login
[
https://issues.apache.org/jira/browse/STORM-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Olson updated STORM-4023:
Labels: jaas kerberos messaging netty (was: kerberos)
> Background periodic Kerberos re-login should use same JAAS configuration as
> initial login
> -
>
> Key: STORM-4023
> URL: https://issues.apache.org/jira/browse/STORM-4023
> Project: Apache Storm
> Issue Type: Bug
> Components: storm-client
>Affects Versions: 2.6.0
>Reporter: Andrew Olson
>Priority: Major
> Labels: jaas, kerberos, messaging, netty
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the
> [Login|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java]
> class, a background thread is started that periodically performs a re-login
> to the Kerberos Ticket Granting Server.
> For the initial login, a custom Configuration instance is
> [created|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L257]
> and [supplied to the LoginContext
> constructor|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L300]
> potentially using a custom JAAS file location.
> However, the background refresh thread does not then subsequently provide the
> JAAS file location or Configuration to the [reLogin
> method|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L222],
> so it tries to construct a LoginContext with [just a context name and
> subject|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L409]
> but no Configuration parameter, which means that the underlying
> {{Configuration.getConfiguration()}} call has to load one from [system
> defaults|https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/jdk-11%2B28/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L242],
> which could possibly specify a different file or none at all.
> In our application where this issue was found, we had set the
> {{java.security.auth.login.config}} value to a valid JAAS file location as a
> Storm client property along with other standard connectivity properties,
> since the [Netty client
> framework|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyClient.java#L61]
> loads it [from the topology
> configuration|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/security/auth/ClientAuthUtils.java#L64].
> It looks like the Netty server framework [does the
> same|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyServer.java#L55]
> as well. The initial login succeeded and the following Storm Nimbus
> interactions were successful, but a while later it lost the ability to
> communicate with Storm with this error being logged,
> {noformat}
> ERROR [Refresh-TGT] org.apache.storm.messaging.netty.Login Could not refresh
> TGT for principal:
> javax.security.auth.login.LoginException: No LoginModules configured for
> StormClient
>at
> java.base/javax.security.auth.login.LoginContext.init(LoginContext.java:267)
>at
> java.base/javax.security.auth.login.LoginContext.(LoginContext.java:385)
>at org.apache.storm.messaging.netty.Login.reLogin(Login.java:409)
>at org.apache.storm.messaging.netty.Login$1.run(Login.java:222)
>at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
> It appears that a viable workaround for this issue is to also set the system
> property,
> {{-Djava.security.auth.login.config=/some/path/jaas.conf}}
> for the application, referencing the same JAAS file location as was set in
> the Storm configuration. After doing so the background refresh thread was
> able to correctly function.
> To address this, we should be able to update the {{reLogin}} method to use
> the same JAAS configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (STORM-4023) Background periodic Kerberos re-login should use same JAAS configuration as initial login
[
https://issues.apache.org/jira/browse/STORM-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Olson updated STORM-4023:
Description:
In the
[Login|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java]
class, a background thread is started that periodically performs a re-login to
the Kerberos Ticket Granting Server.
For the initial login, a custom Configuration instance is
[created|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L257]
and [supplied to the LoginContext
constructor|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L300]
potentially using a custom JAAS file location.
However, the background refresh thread does not then subsequently provide the
JAAS file location or Configuration to the [reLogin
method|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L222],
so it tries to construct a LoginContext with [just a context name and
subject|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L409]
but no Configuration parameter, which means that the underlying
{{Configuration.getConfiguration()}} call has to load one from [system
defaults|https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/jdk-11%2B28/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L242],
which could possibly specify a different file or none at all.
In our application where this issue was found, we had set the
{{java.security.auth.login.config}} value to a valid JAAS file location as a
Storm client property along with other standard connectivity properties, since
the [Netty client
framework|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyClient.java#L61]
loads it [from the topology
configuration|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/security/auth/ClientAuthUtils.java#L64].
It looks like the Netty server framework [does the
same|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyServer.java#L55]
as well. The initial login succeeded and the following Storm Nimbus
interactions were successful, but a while later it lost the ability to
communicate with Storm with this error being logged,
{noformat}
ERROR [Refresh-TGT] org.apache.storm.messaging.netty.Login Could not refresh
TGT for principal:
javax.security.auth.login.LoginException: No LoginModules configured for
StormClient
at
java.base/javax.security.auth.login.LoginContext.init(LoginContext.java:267)
at
java.base/javax.security.auth.login.LoginContext.(LoginContext.java:385)
at org.apache.storm.messaging.netty.Login.reLogin(Login.java:409)
at org.apache.storm.messaging.netty.Login$1.run(Login.java:222)
at java.base/java.lang.Thread.run(Thread.java:829)
{noformat}
It appears that a viable workaround for this issue is to also set the system
property,
{{-Djava.security.auth.login.config=/some/path/jaas.conf}}
for the application, referencing the same JAAS file location as was set in the
Storm configuration. After doing so the background refresh thread was able to
correctly function in our situation.
To address this, we can update the {{reLogin}} method to use the same JAAS
configuration. Furthermore it should use the same callback handler instance
that was originally provided also, instead of creating a new default one.
was:
In the
[Login|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java]
class, a background thread is started that periodically performs a re-login to
the Kerberos Ticket Granting Server.
For the initial login, a custom Configuration instance is
[created|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L257]
and [supplied to the LoginContext
constructor|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L300]
potentially using a custom JAAS file location.
However, the background refresh thread does not then subsequently provide the
JAAS file location or Configuration to the [reLogin
method|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L222],
so it tries to construct a LoginContext with [just a context name and
subject|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L409]
but no Configuration parameter, which means that the underlying
{{Configuration.getConfiguration()}} call has to load one from [system
[jira] [Updated] (STORM-4023) Background periodic Kerberos re-login should use same JAAS configuration as initial login
[
https://issues.apache.org/jira/browse/STORM-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Olson updated STORM-4023:
Description:
In the
[Login|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java]
class, a background thread is started that periodically performs a re-login to
the Kerberos Ticket Granting Server.
For the initial login, a custom Configuration instance is
[created|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L257]
and [supplied to the LoginContext
constructor|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L300]
potentially using a custom JAAS file location.
However, the background refresh thread does not then subsequently provide the
JAAS file location or Configuration to the [reLogin
method|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L222],
so it tries to construct a LoginContext with [just a context name and
subject|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L409]
but no Configuration, which means that the underlying
{{Configuration.getConfiguration()}} call has to load one from [system
defaults|https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/jdk-11%2B28/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L242].
In our application where this issue was found, we had set
{{java.security.auth.login.config}} as a Storm client property along with other
standard connectivity properties, since the [client
framework|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyClient.java#L61]
loads it [from the topology
configuration|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/security/auth/ClientAuthUtils.java#L64].
It looks like the server framework [does the
same|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyServer.java#L55]
as well. The initial login succeeded and the following Storm Nimbus
interactions were successful, but a while later it lost the ability to
communicate with Storm with this error being logged,
{noformat}
ERROR [Refresh-TGT] org.apache.storm.messaging.netty.Login Could not refresh
TGT for principal:
javax.security.auth.login.LoginException: No LoginModules configured for
StormClient
at
java.base/javax.security.auth.login.LoginContext.init(LoginContext.java:267)
at
java.base/javax.security.auth.login.LoginContext.(LoginContext.java:385)
at org.apache.storm.messaging.netty.Login.reLogin(Login.java:409)
at org.apache.storm.messaging.netty.Login$1.run(Login.java:222)
at java.base/java.lang.Thread.run(Thread.java:829)
{noformat}
It appears that a viable workaround for this issue is to also set the system
property,
{{-Djava.security.auth.login.config=/some/path/jaas.conf}}
for the application. After doing so the background refresh thread was able to
correctly function.
To address this, we should be able to update the {{reLogin}} method to use the
same JAAS configuration.
was:
In the
[Login|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java]
class, a background thread is started that periodically performs a re-login to
the Kerberos Ticket Granting Server.
For the initial login, a custom Configuration instance is
[created|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L257]
and [supplied to the LoginContext
constructor|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L300]
potentially using a custom JAAS file location.
However, the background refresh thread does not then subsequently provide the
JAAS file location or Configuration to the [reLogin
method|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L222],
so it tries to construct a LoginContext with [just a context name and
subject|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L409]
but no Configuration, which means that the underlying
{{Configuration.getConfiguration()}} call has to load one from [system
defaults|https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/jdk-11%2B28/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L242].
In our application where this issue was found, we had set
{{java.security.auth.login.config}} as a Storm client property along with other
standard connectivity properties. The initial login succeeded and the following
Storm Nimbus
[jira] [Created] (STORM-4023) Background periodic Kerberos re-login should use same JAAS configuration as initial login
Andrew Olson created STORM-4023:
---
Summary: Background periodic Kerberos re-login should use same
JAAS configuration as initial login
Key: STORM-4023
URL: https://issues.apache.org/jira/browse/STORM-4023
Project: Apache Storm
Issue Type: Bug
Components: storm-client
Affects Versions: 2.6.0
Reporter: Andrew Olson
In the
[Login|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java]
class, a background thread is started that periodically performs a re-login to
the Kerberos Ticket Granting Server.
For the initial login, a custom Configuration instance is
[created|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L257]
and [supplied to the LoginContext
constructor|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L300]
potentially using a custom JAAS file location.
However, the background refresh thread does not then subsequently provide the
JAAS file location or Configuration to the [reLogin
method|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L222],
so it tries to construct a LoginContext with [just a context name and
subject|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L409]
but no Configuration, which means that the underlying
{{Configuration.getConfiguration()}} call has to load one from [system
defaults|https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/jdk-11%2B28/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L242].
In our application where this issue was found, we had set
{{java.security.auth.login.config}} as a Storm client property along with other
standard connectivity properties. The initial login succeeded and the following
Storm Nimbus interactions were successful, but a while later it lost the
ability to communicate with Storm with this error being logged,
{noformat}
ERROR [Refresh-TGT] org.apache.storm.messaging.netty.Login Could not refresh
TGT for principal:
javax.security.auth.login.LoginException: No LoginModules configured for
StormClient
at
java.base/javax.security.auth.login.LoginContext.init(LoginContext.java:267)
at
java.base/javax.security.auth.login.LoginContext.(LoginContext.java:385)
at org.apache.storm.messaging.netty.Login.reLogin(Login.java:409)
at org.apache.storm.messaging.netty.Login$1.run(Login.java:222)
at java.base/java.lang.Thread.run(Thread.java:829)
{noformat}
It appears that a viable workaround for this issue is to also set the system
property,
{{-Djava.security.auth.login.config=/some/path/jaas.conf}}
for the application. After doing so the background refresh thread was able to
correctly function.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (STORM-4023) Background periodic Kerberos re-login should use same JAAS configuration as initial login
[
https://issues.apache.org/jira/browse/STORM-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Olson updated STORM-4023:
Description:
In the
[Login|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java]
class, a background thread is started that periodically performs a re-login to
the Kerberos Ticket Granting Server.
For the initial login, a custom Configuration instance is
[created|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L257]
and [supplied to the LoginContext
constructor|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L300]
potentially using a custom JAAS file location.
However, the background refresh thread does not then subsequently provide the
JAAS file location or Configuration to the [reLogin
method|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L222],
so it tries to construct a LoginContext with [just a context name and
subject|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L409]
but no Configuration parameter, which means that the underlying
{{Configuration.getConfiguration()}} call has to load one from [system
defaults|https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/jdk-11%2B28/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L242],
which could possibly specify a different file or none at all.
In our application where this issue was found, we had set the
{{java.security.auth.login.config}} value to a valid JAAS file location as a
Storm client property along with other standard connectivity properties, since
the [Netty client
framework|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyClient.java#L61]
loads it [from the topology
configuration|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/security/auth/ClientAuthUtils.java#L64].
It looks like the Netty server framework [does the
same|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/KerberosSaslNettyServer.java#L55]
as well. The initial login succeeded and the following Storm Nimbus
interactions were successful, but a while later it lost the ability to
communicate with Storm with this error being logged,
{noformat}
ERROR [Refresh-TGT] org.apache.storm.messaging.netty.Login Could not refresh
TGT for principal:
javax.security.auth.login.LoginException: No LoginModules configured for
StormClient
at
java.base/javax.security.auth.login.LoginContext.init(LoginContext.java:267)
at
java.base/javax.security.auth.login.LoginContext.(LoginContext.java:385)
at org.apache.storm.messaging.netty.Login.reLogin(Login.java:409)
at org.apache.storm.messaging.netty.Login$1.run(Login.java:222)
at java.base/java.lang.Thread.run(Thread.java:829)
{noformat}
It appears that a viable workaround for this issue is to also set the system
property,
{{-Djava.security.auth.login.config=/some/path/jaas.conf}}
for the application, referencing the same JAAS file location as was set in the
Storm configuration. After doing so the background refresh thread was able to
correctly function.
To address this, we should be able to update the {{reLogin}} method to use the
same JAAS configuration.
was:
In the
[Login|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java]
class, a background thread is started that periodically performs a re-login to
the Kerberos Ticket Granting Server.
For the initial login, a custom Configuration instance is
[created|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L257]
and [supplied to the LoginContext
constructor|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L300]
potentially using a custom JAAS file location.
However, the background refresh thread does not then subsequently provide the
JAAS file location or Configuration to the [reLogin
method|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L222],
so it tries to construct a LoginContext with [just a context name and
subject|https://github.com/apache/storm/blob/v2.6.0/storm-client/src/jvm/org/apache/storm/messaging/netty/Login.java#L409]
but no Configuration, which means that the underlying
{{Configuration.getConfiguration()}} call has to load one from [system
defaults|https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/jdk-11%2B28/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L242].
In our application where this issue
