Re: Could/should OsgiConfiguration for JAAS fallback to default configuration

2016-11-28 Thread Jean-Baptiste Onofré 

Thanks Sergiy, I will review.

Regards
JB

On 11/28/2016 03:03 PM, Sergiy Shyrkov wrote:

Hello guys,

we've finally tested the fix successfully on our side and have submitted
it as a pull request: https://github.com/apache/karaf/pull/271

Thank you!

Kind regards
Sergiy

On Thu, 20 Oct 2016 08:59:03 +0200, Benjamin Papez
 wrote:


Hi JB,

thanks for looking into it. I already created a jira:
https://issues.apache.org/jira/browse/KARAF-4784

The workaround with an own login module ain't that easy, because we do
not know the names of all current jaas configurations customers have
today (can be multiple per installation). As I understand with OSGI we
(or they) would need to create one realm per such entry name and the
login module would need to be able to read and copy the default
configuration before osgi overrides it. If OsgiConfiguration would
fallback to the default configuration, no action would be required
(for us and for customers migrating to the new relase with Karaf).

Regards,
Benjamin

Am 18.10.2016 um 18:25 schrieb Jean-Baptiste Onofré:

Hi Benjamin,

your proposal makes sense. I will review, create a Jira, and implement.

In the mean time, as a workaround, I think you can provide your own
login module acting as a bypass.

Regards
JB

On 10/18/2016 06:19 PM, Benjamin Papez wrote:

Hello,

we plan to use Karaf embedded in the next version of our Web
Application, which means that we still start the application server
(Tomcat/JBoss/Websphere). Some of our customers are using a JAAS
configuration, mainly Kerberos for SPNEGO. Unfortunately with the step
to use Karaf the current default JAAS configuration is no longer picked
up and used, because Karaf is setting the OsgiConfiguration object into
Configuration.setConfiguration within OsgiConfiguration.init method.

Is it wanted (by design) to ignore all standard/app-server specific
ways
of JAAS configuration?

I would otherwise suggest a modification to OsgiConfiguration, with
something like:

private Configuration defaultConfiguration;

public void init() {
try {
defaultConfiguration = Configuration.getConfiguration();
} catch (RuntimeException ex) {
//
}
Configuration.setConfiguration(this);
}
...
public AppConfigurationEntry[] getAppConfigurationEntry(String
name) {
JaasRealm realm = null;
for (JaasRealm r : realms) {
if (r.getName().equals(name)) {
if (realm == null || r.getRank() > realm.getRank()) {
realm = r;
}
}
}
if (realm != null) {
return realm.getEntries();
} else if (defaultConfiguration != null) {
   return defaultConfiguration.getAppConfigurationEntry(name);
}
return null;
}

public void refresh() {
if (defaultConfiguration != null) {
defaultConfiguration.refresh();
}
}

This way if no OSGI configured JAAS realm can find an
AppConfigurationEntry, we would still try to get it from the default
JAAS configuration, and our customers could keep the same JAAS
configuration as before. Would implementing this suggestion break
anything in Karaf?

Regards,
Benjamin









--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Could/should OsgiConfiguration for JAAS fallback to default configuration

2016-11-28 Thread Sergiy Shyrkov 

Hello guys,

we've finally tested the fix successfully on our side and have submitted  
it as a pull request: https://github.com/apache/karaf/pull/271


Thank you!

Kind regards
Sergiy

On Thu, 20 Oct 2016 08:59:03 +0200, Benjamin Papez   
wrote:



Hi JB,

thanks for looking into it. I already created a jira:  
https://issues.apache.org/jira/browse/KARAF-4784


The workaround with an own login module ain't that easy, because we do  
not know the names of all current jaas configurations customers have  
today (can be multiple per installation). As I understand with OSGI we  
(or they) would need to create one realm per such entry name and the  
login module would need to be able to read and copy the default  
configuration before osgi overrides it. If OsgiConfiguration would  
fallback to the default configuration, no action would be required (for  
us and for customers migrating to the new relase with Karaf).


Regards,
Benjamin

Am 18.10.2016 um 18:25 schrieb Jean-Baptiste Onofré:

Hi Benjamin,

your proposal makes sense. I will review, create a Jira, and implement.

In the mean time, as a workaround, I think you can provide your own  
login module acting as a bypass.


Regards
JB

On 10/18/2016 06:19 PM, Benjamin Papez wrote:

Hello,

we plan to use Karaf embedded in the next version of our Web
Application, which means that we still start the application server
(Tomcat/JBoss/Websphere). Some of our customers are using a JAAS
configuration, mainly Kerberos for SPNEGO. Unfortunately with the step
to use Karaf the current default JAAS configuration is no longer picked
up and used, because Karaf is setting the OsgiConfiguration object into
Configuration.setConfiguration within OsgiConfiguration.init method.

Is it wanted (by design) to ignore all standard/app-server specific  
ways

of JAAS configuration?

I would otherwise suggest a modification to OsgiConfiguration, with
something like:

private Configuration defaultConfiguration;

public void init() {
try {
defaultConfiguration = Configuration.getConfiguration();
} catch (RuntimeException ex) {
//
}
Configuration.setConfiguration(this);
}
...
public AppConfigurationEntry[] getAppConfigurationEntry(String  
name) {

JaasRealm realm = null;
for (JaasRealm r : realms) {
if (r.getName().equals(name)) {
if (realm == null || r.getRank() > realm.getRank()) {
realm = r;
}
}
}
if (realm != null) {
return realm.getEntries();
} else if (defaultConfiguration != null) {
   return defaultConfiguration.getAppConfigurationEntry(name);
}
return null;
}

public void refresh() {
if (defaultConfiguration != null) {
defaultConfiguration.refresh();
}
}

This way if no OSGI configured JAAS realm can find an
AppConfigurationEntry, we would still try to get it from the default
JAAS configuration, and our customers could keep the same JAAS
configuration as before. Would implementing this suggestion break
anything in Karaf?

Regards,
Benjamin







--
Sergiy Shyrkov
Software Architect
Jahia Solutions Group SA
http://www.jahia.com

Re: Could/should OsgiConfiguration for JAAS fallback to default configuration

2016-10-20 Thread Benjamin Papez 

Hi JB,

thanks for looking into it. I already created a jira: 
https://issues.apache.org/jira/browse/KARAF-4784


The workaround with an own login module ain't that easy, because we do 
not know the names of all current jaas configurations customers have 
today (can be multiple per installation). As I understand with OSGI we 
(or they) would need to create one realm per such entry name and the 
login module would need to be able to read and copy the default 
configuration before osgi overrides it. If OsgiConfiguration would 
fallback to the default configuration, no action would be required (for 
us and for customers migrating to the new relase with Karaf).


Regards,
Benjamin

Am 18.10.2016 um 18:25 schrieb Jean-Baptiste Onofré:

Hi Benjamin,

your proposal makes sense. I will review, create a Jira, and implement.

In the mean time, as a workaround, I think you can provide your own 
login module acting as a bypass.


Regards
JB

On 10/18/2016 06:19 PM, Benjamin Papez wrote:

Hello,

we plan to use Karaf embedded in the next version of our Web
Application, which means that we still start the application server
(Tomcat/JBoss/Websphere). Some of our customers are using a JAAS
configuration, mainly Kerberos for SPNEGO. Unfortunately with the step
to use Karaf the current default JAAS configuration is no longer picked
up and used, because Karaf is setting the OsgiConfiguration object into
Configuration.setConfiguration within OsgiConfiguration.init method.

Is it wanted (by design) to ignore all standard/app-server specific ways
of JAAS configuration?

I would otherwise suggest a modification to OsgiConfiguration, with
something like:

private Configuration defaultConfiguration;

public void init() {
try {
defaultConfiguration = Configuration.getConfiguration();
} catch (RuntimeException ex) {
//
}
Configuration.setConfiguration(this);
}
...
public AppConfigurationEntry[] getAppConfigurationEntry(String 
name) {

JaasRealm realm = null;
for (JaasRealm r : realms) {
if (r.getName().equals(name)) {
if (realm == null || r.getRank() > realm.getRank()) {
realm = r;
}
}
}
if (realm != null) {
return realm.getEntries();
} else if (defaultConfiguration != null) {
   return defaultConfiguration.getAppConfigurationEntry(name);
}
return null;
}

public void refresh() {
if (defaultConfiguration != null) {
defaultConfiguration.refresh();
}
}

This way if no OSGI configured JAAS realm can find an
AppConfigurationEntry, we would still try to get it from the default
JAAS configuration, and our customers could keep the same JAAS
configuration as before. Would implementing this suggestion break
anything in Karaf?

Regards,
Benjamin

Re: Could/should OsgiConfiguration for JAAS fallback to default configuration

2016-10-18 Thread Jean-Baptiste Onofré 

Hi Benjamin,

your proposal makes sense. I will review, create a Jira, and implement.

In the mean time, as a workaround, I think you can provide your own 
login module acting as a bypass.


Regards
JB

On 10/18/2016 06:19 PM, Benjamin Papez wrote:

Hello,

we plan to use Karaf embedded in the next version of our Web
Application, which means that we still start the application server
(Tomcat/JBoss/Websphere). Some of our customers are using a JAAS
configuration, mainly Kerberos for SPNEGO. Unfortunately with the step
to use Karaf the current default JAAS configuration is no longer picked
up and used, because Karaf is setting the OsgiConfiguration object into
Configuration.setConfiguration within OsgiConfiguration.init method.

Is it wanted (by design) to ignore all standard/app-server specific ways
of JAAS configuration?

I would otherwise suggest a modification to OsgiConfiguration, with
something like:

private Configuration defaultConfiguration;

public void init() {
try {
defaultConfiguration = Configuration.getConfiguration();
} catch (RuntimeException ex) {
//
}
Configuration.setConfiguration(this);
}
...
public AppConfigurationEntry[] getAppConfigurationEntry(String name) {
JaasRealm realm = null;
for (JaasRealm r : realms) {
if (r.getName().equals(name)) {
if (realm == null || r.getRank() > realm.getRank()) {
realm = r;
}
}
}
if (realm != null) {
return realm.getEntries();
} else if (defaultConfiguration != null) {
   return defaultConfiguration.getAppConfigurationEntry(name);
}
return null;
}

public void refresh() {
if (defaultConfiguration != null) {
defaultConfiguration.refresh();
}
}

This way if no OSGI configured JAAS realm can find an
AppConfigurationEntry, we would still try to get it from the default
JAAS configuration, and our customers could keep the same JAAS
configuration as before. Would implementing this suggestion break
anything in Karaf?

Regards,
Benjamin


--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Could/should OsgiConfiguration for JAAS fallback to default configuration

2016-10-18 Thread Benjamin Papez 

Hello,

we plan to use Karaf embedded in the next version of our Web 
Application, which means that we still start the application server 
(Tomcat/JBoss/Websphere). Some of our customers are using a JAAS 
configuration, mainly Kerberos for SPNEGO. Unfortunately with the step 
to use Karaf the current default JAAS configuration is no longer picked 
up and used, because Karaf is setting the OsgiConfiguration object into 
Configuration.setConfiguration within OsgiConfiguration.init method.


Is it wanted (by design) to ignore all standard/app-server specific ways 
of JAAS configuration?


I would otherwise suggest a modification to OsgiConfiguration, with 
something like:


private Configuration defaultConfiguration;

public void init() {
try {
defaultConfiguration = Configuration.getConfiguration();
} catch (RuntimeException ex) {
//
}
Configuration.setConfiguration(this);
}
...
public AppConfigurationEntry[] getAppConfigurationEntry(String name) {
JaasRealm realm = null;
for (JaasRealm r : realms) {
if (r.getName().equals(name)) {
if (realm == null || r.getRank() > realm.getRank()) {
realm = r;
}
}
}
if (realm != null) {
return realm.getEntries();
} else if (defaultConfiguration != null) {
   return defaultConfiguration.getAppConfigurationEntry(name);
}
return null;
}

public void refresh() {
if (defaultConfiguration != null) {
defaultConfiguration.refresh();
}
}

This way if no OSGI configured JAAS realm can find an 
AppConfigurationEntry, we would still try to get it from the default 
JAAS configuration, and our customers could keep the same JAAS 
configuration as before. Would implementing this suggestion break 
anything in Karaf?


Regards,
Benjamin