July 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-487) Improved handling of artifact updates

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-487?page=com.atlassian.jira.plugin.... ] Brett Meyer closed SRAMP-487. ----------------------------- Fix Version/s: (was: 0.6.0) Resolution: Duplicate Issue Closing this -- SRAMP-507 and SRAMP-508 encapsulate and expand upon the concepts. > Improved handling of artifact updates > ------------------------------------- > > Key: SRAMP-487 > URL: https://issues.jboss.org/browse/SRAMP-487 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Currently, artifacts can be deployed multiple times, duplicating extracted/derived content. [~eric.wittmann] pointed out that the spec is a little ambiguous with regards to updating artifacts. My gut reaction is that it probably shouldn't be allowed (think Nexus). However, snapshots should probably be updatable, and therefore would need extracted/derived content (and their relationships) removed prior to updating. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-436) Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-436?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-436: -------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/85, https://github.com/Governance/s-ramp/pull/455, https://github.com/Governance/dtgov/pull/206 (was: https://github.com/Governance/overlord-commons/pull/85, https://github.com/Governance/s-ramp/pull/455) > Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default > -------------------------------------------------------------------------- > > Key: SRAMP-436 > URL: https://issues.jboss.org/browse/SRAMP-436 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently we're not signing the saml assertions. We need to do that. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-507?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-507: -------------------------------- Description: Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) When deploying a snapshot artifact, maven will include a timestamp in the filename. The maven repository facade *and* the s-ramp wagon should be updated to store this timestamp info in a new s-ramp property (see above). In addition, the s-ramp wagon should no longer *ever* attempt to update an artifact. Here is what it should do: h4. Release artifacts * If this artifact (GAV) already exists in s-ramp, fail * If this artifact doesn't yet exist, add it h4. Snapshot artifacts * If this artifact (GAV + timestamp) already exists in s-ramp, fail * If this artifact doesn't yet exist, add it along with its timestamp information was: Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) Create a new artifact every time a different timestamp of the same artifact is uploaded. It would be exactly as maven is doing. Right now we update the content of the artifact instead of creating a new one. > Modify way the snapshot artifacts are stored in s-ramp > ------------------------------------------------------ > > Key: SRAMP-507 > URL: https://issues.jboss.org/browse/SRAMP-507 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.5.0 > > > Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) > When deploying a snapshot artifact, maven will include a timestamp in the filename. The maven repository facade *and* the s-ramp wagon should be updated to store this timestamp info in a new s-ramp property (see above). In addition, the s-ramp wagon should no longer *ever* attempt to update an artifact. Here is what it should do: > h4. Release artifacts > * If this artifact (GAV) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it > h4. Snapshot artifacts > * If this artifact (GAV + timestamp) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it along with its timestamp information -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-508) Restrict s-ramp artifacts depends on the environment

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-508?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-508: -------------------------------- Description: By default the S-RAMP Maven integration should not allow maven snapshots to be deployed to the s-ramp repository (since this is not a use-case we want to encourage). However, we are planning to support maven snapshots in the code via a flag to enable/disable the support. This flag will be consumed by the maven repository facade. The flag (e.g. s-ramp.maven.enable-snapshots) will default to *false* unless the S-RAMP runtime itself is a SNAPSHOT. This will make it easier for us during development of s-ramp and dtgov to test out our demos and dtgov seed data without changing the versions of those artifacts in their respective pom.xml files. So in summary - the maven repo facade will not allow SNAPSHOT artifacts to be deployed unless the flag is set to true *or* the current s-ramp runtime version is a snapshot version. was: The main idea proposed by Gary is to avoid snapshots artifacts in production. The solution proposed by Eric is to recognize if the s-ramp artifact deployed contains the SNAPSHOT keyword. Then: In case it contains SNAPSHOT: allow Snapshots and Released artifacts. Not contains SNAPSHOT: allow just Released artifacts. > Restrict s-ramp artifacts depends on the environment > ----------------------------------------------------- > > Key: SRAMP-508 > URL: https://issues.jboss.org/browse/SRAMP-508 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > By default the S-RAMP Maven integration should not allow maven snapshots to be deployed to the s-ramp repository (since this is not a use-case we want to encourage). However, we are planning to support maven snapshots in the code via a flag to enable/disable the support. This flag will be consumed by the maven repository facade. The flag (e.g. s-ramp.maven.enable-snapshots) will default to *false* unless the S-RAMP runtime itself is a SNAPSHOT. > This will make it easier for us during development of s-ramp and dtgov to test out our demos and dtgov seed data without changing the versions of those artifacts in their respective pom.xml files. > So in summary - the maven repo facade will not allow SNAPSHOT artifacts to be deployed unless the flag is set to true *or* the current s-ramp runtime version is a snapshot version. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-436) Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-436?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-436: -------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/85, https://github.com/Governance/s-ramp/pull/455 > Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default > -------------------------------------------------------------------------- > > Key: SRAMP-436 > URL: https://issues.jboss.org/browse/SRAMP-436 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently we're not signing the saml assertions. We need to do that. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp

by David virgil naranjo (JIRA)

[ https://issues.jboss.org/browse/SRAMP-507?page=com.atlassian.jira.plugin.... ] David virgil naranjo updated SRAMP-507: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/454 > Modify way the snapshot artifacts are stored in s-ramp > ------------------------------------------------------ > > Key: SRAMP-507 > URL: https://issues.jboss.org/browse/SRAMP-507 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.5.0 > > > Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) > Create a new artifact every time a different timestamp of the same artifact is uploaded. It would be exactly as maven is doing. Right now we update the content of the artifact instead of creating a new one. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-445) SSO not working on Tomcat

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-445?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on SRAMP-445: ----------------------------------- +1, especially if reverting would be fairly invasive. Outside of possibly Fuse/EAP, SSO seems like a "really nice to have", but definitely not a blocker. Would creating a Tomcat issue, providing some context, and simply attaching an overlord-idp.war suffice? I'm wondering if creating a from-scratch standalone test would be worth the effort, depending on what they actually need to debug... > SSO not working on Tomcat > ------------------------- > > Key: SRAMP-445 > URL: https://issues.jboss.org/browse/SRAMP-445 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.6.0 > > > The IDP isn't quite working as an SSO provider when running in Tomcat. The SP properly redirects to the IDP but the IDP is requiring the user to authenticate again, even though they already have. To reproduce: > 1) run both s-ramp and dtgov on tomcat > 2) open browser, navigate to s-ramp-ui > 3) log in > 4) click on Design Time Governance > At this point you will have to authenticate again. This is wrong. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-380) Passwords in clear text when running in Fuse 6.1

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-380?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on SRAMP-380: ----------------------------------- >From Claus: "I think etc/users.properties gets encrypted when fuse 6.1 startup. So you can add the users with cleartext password, but fuse should resave the file with encrypted passwords." If that's the case, we may want to look into appending *all* of our user properties into Fuse's etc/user.properties, rather than copying over our own file. > Passwords in clear text when running in Fuse 6.1 > ------------------------------------------------ > > Key: SRAMP-380 > URL: https://issues.jboss.org/browse/SRAMP-380 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > When we install into JBoss EAP we make sure that we don't have any clear text passwords in any configuration files. This is made possible by using the Vault, which allows us to store passwords in the vault and then refer to those vault locations from our config files. > I don't know if there is something similar to be done in Fuse 6.1 > In addition, the login credentials for supported users in EAP are not stored in clear text (the EAP Application Realm config files store an encrypted version of the passwords). > In Fuse 6.1 we are storing the login user credentials in a users.properties file in clear text. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-507?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on SRAMP-507: ----------------------------------- Relates to SRAMP-487 > Modify way the snapshot artifacts are stored in s-ramp > ------------------------------------------------------ > > Key: SRAMP-507 > URL: https://issues.jboss.org/browse/SRAMP-507 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.5.0 > > > Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) > Create a new artifact every time a different timestamp of the same artifact is uploaded. It would be exactly as maven is doing. Right now we update the content of the artifact instead of creating a new one. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-508) Restrict s-ramp artifacts depends on the environment

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-508?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on SRAMP-508: ----------------------------------- Relates to SRAMP-487 > Restrict s-ramp artifacts depends on the environment > ----------------------------------------------------- > > Key: SRAMP-508 > URL: https://issues.jboss.org/browse/SRAMP-508 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > The main idea proposed by Gary is to avoid snapshots artifacts in production. > The solution proposed by Eric is to recognize if the s-ramp artifact deployed contains the SNAPSHOT keyword. Then: > In case it contains SNAPSHOT: allow Snapshots and Released artifacts. > Not contains SNAPSHOT: allow just Released artifacts. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues July 2014