1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
Re: [EXTERNAL MESSAGE] Re: [cf-dev] Using SAML 2 Bearer token with our own UAA Server #uaa

Shetty, Viraj S [CTR]
 
Edited

Thanks.  I digged into this a little deeper. During the SAML verification, confirmed is never TRUE and that’s why it gives the following error

 

2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT Caused by: org.opensaml.common.SAMLException: Assertion invalidated by subject confirmation - can't be confirmed by the bearer method

 

 

   SPSSODescriptor spssoDescriptor = (SPSSODescriptor) context.getLocalEntityRoleMetadata();

   for (AssertionConsumerService service : spssoDescriptor.getAssertionConsumerServices()) {

        if (context.getCommunicationProfileId().equals(service.getBinding()) && service.getLocation().equals(data.getRecipient())) {

             confirmed = true;

        }

   }

 

Here are the consumer assertion services defined in my UAA metadata.

 

            <md:AssertionConsumerService

                  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

                  Location="https:///saml/SSO/alias/cloudfoundry-saml-login-dev"

                  index="0" isDefault="true" />

            <md:AssertionConsumerService

                  Binding="urn:oasis:names:tc:SAML:2.0:bindings:URI"

                  Location="https:///oauth/token/alias/cloudfoundry-saml-login-dev"

                  index="1" />

 

The SAML Assertion that comes in – has the following

 

      <Subject>

            <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">HIDDEN</NameID>

            <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

                  <SubjectConfirmationData InResponseTo=""

                        NotOnOrAfter=""

                        Recipient="https:///saml/SSO/alias/cloudfoundry-saml-login-dev" />

            </SubjectConfirmation>

      </Subject>

 

 

See that the recipient matches with https:///saml/SSO/alias/cloudfoundry-saml-login-dev but I think the Binding does not match (in the code I am not sure what binding is matched to. Is it Method ?) .

 

Do I have to change my uaa.yml to somehow add a new Assertion Consumer Service ?

 

Viraj Shetty

 

 

From: cf-dev@... <cf-dev@...> On Behalf Of Filip Hanik
Sent: Tuesday, December 10, 2019 6:49 PM
To: CF Developers Mailing List <cf-dev@...>
Subject: [EXTERNAL MESSAGE] Re: [cf-dev] Using SAML 2 Bearer token with our own UAA Server #uaa

 

1. Take a look at the endpoint `/saml/metadata` on your server. For example https://login.run.pivotal.io/saml/metadata

 

In the metadata, take a look at: urn:oasis:names:tc:SAML:2.0:bindings:URI binding, for the exact location to POST your Assertion

https://login.run.pivotal.io/oauth/token/alias/login.run.pivotal.io" index="1"/>

 

2. You can have the NameID encrypted, not the assertion itself.

 

Correct: 

Incorrect:

Incorrect:

 

3. A fully working example you can run in your Debugger can be viewed here (no server required)

 

 

 

 

 

On Tue, Dec 10, 2019 at 2:07 PM vshetty via Lists.Cloudfoundry.Org <vshetty=fdic.gov@...> wrote:

Still having issues. I tried several things and they all seem to fail. 

1. Per the documenatation, the URL should go to http://vyscu3.localhost:8080/uaa/oauth/token/alias/vyscu3.cloudfoundry-saml-login. For my environment, this should probably be 

http:///uaa/oauth/token/alias/cloudfoundry-saml-login-dev 

How do I find if this URL is correct ? The receipient in the SAML Asserrtion is https:///saml/SSO/alias/cloudfoundry-saml-login-dev. tried this as well. 

2. When i used with encrypted assertion below, i get the following exception 

 

 

    2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT java.lang.ClassCastException: class org.opensaml.saml2.core.impl.EncryptedAssertionImpl cannot be

 cast to class org.opensaml.saml2.core.Assertion (org.opensaml.saml2.core.impl.EncryptedAssertionImpl and org.opensaml.saml2.core.Assertion are in unna

 med module of loader org.apache.catalina.loader.ParallelWebappClassLoader @3ed242a4)

    2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT     at org.cloudfoundry.identity.uaa.authentication.SamlAssertionDecoder.doDecode(SamlAssertionDec

 oder.java:97) ~[cloudfoundry-identity-server-74.5.0.jar:?]

    2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT     at org.opensaml.ws.message.decoder.BaseMessageDecoder.decode(BaseMessageDecoder.java:79) ~[ope

nws-1.5.6.jar:?]

 

 

 3. then i tried unencrypted assertion, which gave me another exception 

 

 

 2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT Caused by: org.opensaml.common.SAMLException: Assertion invalidated by subject confirmation - can'

t be confirmed by the bearer method

   2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT     at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifySubject(WebSSOProf

ileConsumerImpl.java:400)

   2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT     at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertion(WebSSOPr

ofileConsumerImpl.java:296)

   2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT     at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationRes

ponse(WebSSOProfileConsumerImpl.java:214)

UAA does not seem to like the subject. Looking at the subject confirmation tag, there is attribute 'method' which is 'urn:oasis:names:tc:SAML:2.0:cm:bearer'

Any ideas ? IS there any expanation other than the UAA Api ? 

 
Re: Using SAML 2 Bearer token with our own UAA Server #uaa

Filip Hanik
 

1. Take a look at the endpoint `/saml/metadata` on your server. For example https://login.run.pivotal.io/saml/metadata

In the metadata, take a look at: urn:oasis:names:tc:SAML:2.0:bindings:URI binding, for the exact location to POST your Assertion
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:URI" Location="https://login.run.pivotal.io/oauth/token/alias/login.run.pivotal.io" index="1"/>

2. You can have the NameID encrypted, not the assertion itself.

Correct: <saml:Assertion>
Incorrect: <samlp:Response>
Incorrect: <saml:EncryptedAssertion>

3. A fully working example you can run in your Debugger can be viewed here (no server required)





On Tue, Dec 10, 2019 at 2:07 PM vshetty via Lists.Cloudfoundry.Org <vshetty=fdic.gov@...> wrote:
Still having issues. I tried several things and they all seem to fail. 

1. Per the documenatation, the URL should go to http://vyscu3.localhost:8080/uaa/oauth/token/alias/vyscu3.cloudfoundry-saml-login. For my environment, this should probably be 

http://<host>/uaa/oauth/token/alias/cloudfoundry-saml-login-dev 

How do I find if this URL is correct ? The receipient in the SAML Asserrtion is https://<host>/saml/SSO/alias/cloudfoundry-saml-login-dev. tried this as well. 

2. When i used with encrypted assertion below, i get the following exception 

<EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion"><xenc:EncryptedData ......
 
    2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT java.lang.ClassCastException: class org.opensaml.saml2.core.impl.EncryptedAssertionImpl cannot be
 cast to class org.opensaml.saml2.core.Assertion (org.opensaml.saml2.core.impl.EncryptedAssertionImpl and org.opensaml.saml2.core.Assertion are in unna
 med module of loader org.apache.catalina.loader.ParallelWebappClassLoader @3ed242a4)
    2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT     at org.cloudfoundry.identity.uaa.authentication.SamlAssertionDecoder.doDecode(SamlAssertionDec
 oder.java:97) ~[cloudfoundry-identity-server-74.5.0.jar:?]
    2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT     at org.opensaml.ws.message.decoder.BaseMessageDecoder.decode(BaseMessageDecoder.java:79) ~[ope
nws-1.5.6.jar:?]
 
 
 3. then i tried unencrypted assertion, which gave me another exception 
 
 
 2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT Caused by: org.opensaml.common.SAMLException: Assertion invalidated by subject confirmation - can'
t be confirmed by the bearer method
   2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT     at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifySubject(WebSSOProf
ileConsumerImpl.java:400)
   2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT     at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertion(WebSSOPr
ofileConsumerImpl.java:296)
   2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT     at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationRes
ponse(WebSSOProfileConsumerImpl.java:214)

UAA does not seem to like the subject. Looking at the subject confirmation tag, there is attribute 'method' which is 'urn:oasis:names:tc:SAML:2.0:cm:bearer'

Any ideas ? IS there any expanation other than the UAA Api ? 
Re: Using SAML 2 Bearer token with our own UAA Server #uaa

Shetty, Viraj S [CTR]
 

Still having issues. I tried several things and they all seem to fail. 

1. Per the documenatation, the URL should go to http://vyscu3.localhost:8080/uaa/oauth/token/alias/vyscu3.cloudfoundry-saml-login. For my environment, this should probably be 

http://<host>/uaa/oauth/token/alias/cloudfoundry-saml-login-dev 

How do I find if this URL is correct ? The receipient in the SAML Asserrtion is https://<host>/saml/SSO/alias/cloudfoundry-saml-login-dev. tried this as well. 

2. When i used with encrypted assertion below, i get the following exception 

<EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion"><xenc:EncryptedData ......
 
    2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT java.lang.ClassCastException: class org.opensaml.saml2.core.impl.EncryptedAssertionImpl cannot be
 cast to class org.opensaml.saml2.core.Assertion (org.opensaml.saml2.core.impl.EncryptedAssertionImpl and org.opensaml.saml2.core.Assertion are in unna
 med module of loader org.apache.catalina.loader.ParallelWebappClassLoader @3ed242a4)
    2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT     at org.cloudfoundry.identity.uaa.authentication.SamlAssertionDecoder.doDecode(SamlAssertionDec
 oder.java:97) ~[cloudfoundry-identity-server-74.5.0.jar:?]
    2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT     at org.opensaml.ws.message.decoder.BaseMessageDecoder.decode(BaseMessageDecoder.java:79) ~[ope
nws-1.5.6.jar:?]
 
 
 3. then i tried unencrypted assertion, which gave me another exception 
 
 
 2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT Caused by: org.opensaml.common.SAMLException: Assertion invalidated by subject confirmation - can'
t be confirmed by the bearer method
   2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT     at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifySubject(WebSSOProf
ileConsumerImpl.java:400)
   2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT     at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertion(WebSSOPr
ofileConsumerImpl.java:296)
   2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT     at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationRes
ponse(WebSSOProfileConsumerImpl.java:214)

UAA does not seem to like the subject. Looking at the subject confirmation tag, there is attribute 'method' which is 'urn:oasis:names:tc:SAML:2.0:cm:bearer'

Any ideas ? IS there any expanation other than the UAA Api ? 
Re: Using SAML 2 Bearer token with our own UAA Server #uaa

Filip Hanik
 

Assertion can be signed, encrypted(name ID) or both.

Unsigned and Unencrypted is not recommended.

Filip

On Tue, Dec 10, 2019 at 9:44 AM vshetty via Lists.Cloudfoundry.Org <vshetty=fdic.gov@...> wrote:
Thanks Filip. You are correct and thanks for pointing it out.  I will pass Assertion and see what happens. 

As a side question - I am assuming that the Assertion would have to be unencrypted. right ? Does this matter ? 

Thanks,
Viraj 

Re: Using SAML 2 Bearer token with our own UAA Server #uaa

Shetty, Viraj S [CTR]
 

Thanks Filip. You are correct and thanks for pointing it out.  I will pass Assertion and see what happens. 

As a side question - I am assuming that the Assertion would have to be unencrypted. right ? Does this matter ? 

Thanks,
Viraj 
Re: Using SAML 2 Bearer token with our own UAA Server #uaa

Martijn de Boer
 

Hi,
 
For SAML Bearer an Assertion object is expected as bas64-url(base64(assertion)). Looks like you are send not the Assertion, but the SAML response object.
 
See
 
10:44:22.088: [APP/PROC/WEB.0] java.lang.ClassCastException: class org.opensaml.saml2.core.impl.ResponseImpl cannot be cast to class org.opensaml.saml2.core.Assertion (org.opensaml.saml2.core.impl.ResponseImpl and org.opensaml.saml2.core.Assertion are in unnamed module of loader org.apache.catalina.loader.ParallelWebappClassLoader @3ed242a4)
 
Regards,
 
Martijn
 
Gesendet: Dienstag, 10. Dezember 2019 um 18:06 Uhr
Von: "vshetty via Lists.Cloudfoundry.Org" <vshetty=fdic.gov@...>
An: cf-dev@...
Betreff: [cf-dev] Using SAML 2 Bearer token with our own UAA Server #uaa
I am trying to prototype a situation where a user is already authenticated to an On-prem application using ADFS using SAML. Now, this application needs to call a web service deployed on cloud.gov (Cloud foundry). We also have our own instance of UAA running in cloud.gov which is used for authorization. IF the user has already been authenticated with the on-prem application, then it should be possible to exchange the SAML token with an OAuth Bearer token with the UAA Server installed on cloud.gov. So, as a prototype I obtained the SAML token for a user and tried to exchange with  OAuth Bearer token by calling the UAA on cloud.gov as specified in 

https://docs.cloudfoundry.org/api/uaa/version/74.4.0/index.html#saml2-bearer-grant

However, I keep getting an error no matter what. I even decrypted the SAML token and then sent the Base64 URI but still no luck. The error I am getting is the following

Anyone has any ideas why this might be happening ? 
 
10:44:22.088: [APP/PROC/WEB.0] [2019-12-10 15:44:22.086] uaa - 7 [http-nio-8080-exec-2] .... ERROR --- SecurityFilterChainPostProcessor$HttpsEnforcementFilter: Uncaught Exception:
10:44:22.088: [APP/PROC/WEB.0] java.lang.ClassCastException: class org.opensaml.saml2.core.impl.ResponseImpl cannot be cast to class org.opensaml.saml2.core.Assertion (org.opensaml.saml2.core.impl.ResponseImpl and org.opensaml.saml2.core.Assertion are in unnamed module of loader org.apache.catalina.loader.ParallelWebappClassLoader @3ed242a4)
10:44:22.088: [APP/PROC/WEB.0] at org.cloudfoundry.identity.uaa.authentication.SamlAssertionDecoder.doDecode(SamlAssertionDecoder.java:97) ~[cloudfoundry-identity-server-74.5.0.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.opensaml.ws.message.decoder.BaseMessageDecoder.decode(BaseMessageDecoder.java:79) ~[openws-1.5.6.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.opensaml.saml2.binding.decoding.BaseSAML2MessageDecoder.decode(BaseSAML2MessageDecoder.java:70) ~[opensaml-2.6.6.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.springframework.security.saml.processor.SAMLProcessorImpl.retrieveMessage(SAMLProcessorImpl.java:105) ~[spring-security-saml2-core-1.0.9.RELEASE.jar:1.0.9.RELEASE]
10:44:22.088: [APP/PROC/WEB.0] at org.springframework.security.saml.processor.SAMLProcessorImpl.retrieveMessage(SAMLProcessorImpl.java:172) ~[spring-security-saml2-core-1.0.9.RELEASE.jar:1.0.9.RELEASE]
10:44:22.088: [APP/PROC/WEB.0] at org.springframework.security.saml.SAMLProcessingFilter.attemptAuthentication(SAMLProcessingFilter.java:85) ~[spring-security-saml2-core-1.0.9.RELEASE.jar:1.0.9.RELEASE]
10:44:22.088: [APP/PROC/WEB.0] at org.cloudfoundry.identity.uaa.authentication.BackwardsCompatibleTokenEndpointAuthenticationFilter.attemptTokenAuthentication(BackwardsCompatibleTokenEndpointAuthenticationFilter.java:218) ~[cloudfoundry-identity-server-74.5.0.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.cloudfoundry.identity.uaa.authentication.BackwardsCompatibleTokenEndpointAuthenticationFilter.doFilter(BackwardsCompatibleTokenEndpointAuthenticationFilter.java:114) ~[cloudfoundry-identity-server-74.5.0.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334) ~[spring-security-web-5.1.6.RELEASE.jar:5.1.6.RELEASE]
10:44:22.088: [APP/PROC/WEB.0] at org.cloudfoundry.identity.uaa.authentication.ClientBasicAuthenticationFilter.doFilterInternal(ClientBasicAuthenticationFilter.java:142) ~[cloudfoundry-identity-server-74.5.0.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119) ~[spring-web-5.1.10.RELEASE.jar:5.1.10.RELEASE]
 
Re: Using SAML 2 Bearer token with our own UAA Server #uaa

Filip Hanik
 

ClassCastException: class org.opensaml.saml2.core.impl.ResponseImpl cannot be cast to class org.opensaml.saml2.core.Assertion

The  SAML 2 Bearer Grant expects an Assertion XML in the parameter `assertion`
You are currently passing a `Response` XML data instead.

Correct: <saml:Assertion>
Incorrect: <samlp:Response>
Using SAML 2 Bearer token with our own UAA Server #uaa

Shetty, Viraj S [CTR]
 

I am trying to prototype a situation where a user is already authenticated to an On-prem application using ADFS using SAML. Now, this application needs to call a web service deployed on cloud.gov (Cloud foundry). We also have our own instance of UAA running in cloud.gov which is used for authorization. IF the user has already been authenticated with the on-prem application, then it should be possible to exchange the SAML token with an OAuth Bearer token with the UAA Server installed on cloud.gov. So, as a prototype I obtained the SAML token for a user and tried to exchange with  OAuth Bearer token by calling the UAA on cloud.gov as specified in 

https://docs.cloudfoundry.org/api/uaa/version/74.4.0/index.html#saml2-bearer-grant

However, I keep getting an error no matter what. I even decrypted the SAML token and then sent the Base64 URI but still no luck. The error I am getting is the following

Anyone has any ideas why this might be happening ? 

10:44:22.088: [APP/PROC/WEB.0] [2019-12-10 15:44:22.086] uaa - 7 [http-nio-8080-exec-2] .... ERROR --- SecurityFilterChainPostProcessor$HttpsEnforcementFilter: Uncaught Exception:
10:44:22.088: [APP/PROC/WEB.0] java.lang.ClassCastException: class org.opensaml.saml2.core.impl.ResponseImpl cannot be cast to class org.opensaml.saml2.core.Assertion (org.opensaml.saml2.core.impl.ResponseImpl and org.opensaml.saml2.core.Assertion are in unnamed module of loader org.apache.catalina.loader.ParallelWebappClassLoader @3ed242a4)
10:44:22.088: [APP/PROC/WEB.0] at org.cloudfoundry.identity.uaa.authentication.SamlAssertionDecoder.doDecode(SamlAssertionDecoder.java:97) ~[cloudfoundry-identity-server-74.5.0.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.opensaml.ws.message.decoder.BaseMessageDecoder.decode(BaseMessageDecoder.java:79) ~[openws-1.5.6.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.opensaml.saml2.binding.decoding.BaseSAML2MessageDecoder.decode(BaseSAML2MessageDecoder.java:70) ~[opensaml-2.6.6.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.springframework.security.saml.processor.SAMLProcessorImpl.retrieveMessage(SAMLProcessorImpl.java:105) ~[spring-security-saml2-core-1.0.9.RELEASE.jar:1.0.9.RELEASE]
10:44:22.088: [APP/PROC/WEB.0] at org.springframework.security.saml.processor.SAMLProcessorImpl.retrieveMessage(SAMLProcessorImpl.java:172) ~[spring-security-saml2-core-1.0.9.RELEASE.jar:1.0.9.RELEASE]
10:44:22.088: [APP/PROC/WEB.0] at org.springframework.security.saml.SAMLProcessingFilter.attemptAuthentication(SAMLProcessingFilter.java:85) ~[spring-security-saml2-core-1.0.9.RELEASE.jar:1.0.9.RELEASE]
10:44:22.088: [APP/PROC/WEB.0] at org.cloudfoundry.identity.uaa.authentication.BackwardsCompatibleTokenEndpointAuthenticationFilter.attemptTokenAuthentication(BackwardsCompatibleTokenEndpointAuthenticationFilter.java:218) ~[cloudfoundry-identity-server-74.5.0.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.cloudfoundry.identity.uaa.authentication.BackwardsCompatibleTokenEndpointAuthenticationFilter.doFilter(BackwardsCompatibleTokenEndpointAuthenticationFilter.java:114) ~[cloudfoundry-identity-server-74.5.0.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334) ~[spring-security-web-5.1.6.RELEASE.jar:5.1.6.RELEASE]
10:44:22.088: [APP/PROC/WEB.0] at org.cloudfoundry.identity.uaa.authentication.ClientBasicAuthenticationFilter.doFilterInternal(ClientBasicAuthenticationFilter.java:142) ~[cloudfoundry-identity-server-74.5.0.jar:?]
10:44:22.088: [APP/PROC/WEB.0] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119) ~[spring-web-5.1.10.RELEASE.jar:5.1.10.RELEASE]
 
IMPORTANT NOTICE: [python-buildpack] End of support for Python versions 2.7.x after 2020-01-01

Kashyap Vedurmudi <kvedurmudi@...>
 

The first release of the Python buildpack after January 1, 2020 will no longer include Python versions 2.7.x. These Python versions will no longer be supported upstream.[1] Please migrate your Python apps to supported versions of Python before that time.


As 2.7.x is the current default for the Python version in the buildpack, the default Python version will be updated to 3.8.x as a part of this removal. If you’d like to use a different Python version, please configure your application to select that version[2]. As always, the buildpacks team is happy to answer questions you may have about this deprecation in the #buildpacks Slack channel.


Please note that as miniconda2 depends on Python 2.X, miniconda2 will also be removed as a part of this release. Miniconda3 is currently available in the buildpack.


[1] https://www.python.org/dev/peps/pep-0373/

[2] https://docs.cloudfoundry.org/buildpacks/python/index.html#runtime



Thanks,

Kashyap Vedurmudi, CF Buildpacks PM
IMPORTANT NOTICE: [nodejs-buildpack] End of support for Node.js versions 8.x after 2020-01-05

Elliott Shanks
 

The first release of the Node.js buildpack after January 5, 2020 will no longer include Node.js versions 8.x. These Node.js versions will no longer be supported upstream.[1] Please migrate your Node.js apps to supported versions of Node.js before that time.


Note: While the default version of Node.js in the Node.js buildpack is 10.x, it is recommended that you ensure your Node.js applications are not specifying a Node.js version of 8.x in either a buildpack.yml, .nvmrc, or package.json files. As always, the buildpacks team is happy to answer questions you may have about this deprecation in the #buildpacks Slack channel.


[1] https://nodejs.org/en/about/releases/


Thanks,

Elliott Shanks, CF Buildpacks PM
Routing Release 0.196.0

Keshav Sharma <ksharma@...>
 

Hello CF community, 

Release Highlights

  • Platform Operators can now know the maximum impact from a single component on their database details

Application Developers can see metrics that help them more easily determine if latency is coming from the gorouter or their application details

  • Platform Operators can now leverage jq on the router vm to debug more easily details

  • Application Developers can leverage w3c trace context to experience better:

    • Visibility into the behavior of distributed applications
    • Management of micro-service applications details

      Manifest Property Changes

Job Property 0.195.0 Default 0.196.0 Default
gorouter tracing.enable_w3c Did Not Exist False
gorouter tracing.w3c_tenant_id Did Not Exist “”

CF-Bosh Networking
CF CLI 6.48.0 released today

Mukesh Gadiya
 

Hi everyone,

The CF CLI team released v6.48.0 today which includes improved behavior of random-route flag, few bug fixes and and windows installer update. 

Please reach out to us in cloudfoundry #cli slack channel if you have any questions. Thanks.

Best,
CF CLI team
IMPORTANT NOTICE: [.NET Core buildpack] End of support for .NET Core versions 2.2.x after 2020-01-04

Elliott Shanks
 

The first release of the .NET Core buildpack after January 4, 2020 will no longer include .NET Core versions 2.2.x. These .NET Core versions will no longer be supported upstream.[1] Please migrate your .NET Core apps to supported versions of .NET Core before that time.


Additionally, the default version of .NET Core will change from 2.2.x to 3.1.x at this time.


Note: Unless you are manually specifying a version of .NET Core for the buildpack to use, or you have customized your .NET Core buildpack, no action is required.


[1] https://dotnet.microsoft.com/platform/support/policy/dotnet-core


Thanks,

Elliott Shanks, CF Buildpacks PM
Re: Eirini is 1.0!

Julian Fischer
 

I am delighted. Congratulations!

Am 12.11.2019 um 12:45 schrieb Julz Friedman <julz.friedman@...>:

Hi cloud foundries, 

We’re happy to announce the Eirini team has hit our internal “1.0” milestone and shipped a release marked as 1.0 [0]!.

This means we believe the core Eirini component is stable and ready to use (although there are some optional features - such as the new v3 API, tasks and container-to-container networking support - that are only available in the Diego backend, for now). 

This work would not have been possible without contributions from across the Cloud Foundry community, but especially from IBM, Pivotal, SAP, SUSE and Google.

# What is Eirini?

Eirini brings the simplicity of `cf push` to Kubernetes. Kubernetes has quickly become the de-facto standard container scheduler across the cloud community, and now - via Eirini - Cloud Foundry users can take advantage of this powerful technology to put their containers on servers. Even better (in my opinion anyway), Kubernetes users can now try out the Cloud Foundry developer experience in a native, easy and interoperable way -- which means: less YML, more code.

# How can I try Eirini / Cloud Foundry on Kubernetes?

Eirini-based Cloud Foundry is already available commercially as a technology preview from IBM Cloud, SUSE and Pivotal. You can also deploy your own Eirini from the open-source bits by following the instructions in the eirini-release repository [1] (these are still a little harder than we'd like them to be, but there's lots of work going on in the wider eiriniverse to make them better!) - and let us know how you get on (see next paragraph!).

# Talking to us:

We’re available in Cloud Foundry slack in the #eirini-dev and #cf-for-k8s channels, and there’s a cross-community meeting [2] discussing CF on Kubernetes and the broader “Eiriniverse” every second Tuesday which you can find in the CF Community Calendar [3] - everyone is very very welcome to join and help steer the direction of the projects.

Thanks y’all-
The Eirini Team,

[3]: https://www.cloudfoundry.org/community-calendar/
Upcoming changes to bosh-linux-stemcell-builder

Aakash Shah
 

Hey all,
In an effort to have the bosh-linux-stemcell-builder be more maintainable for the bosh team, we are hoping to remove build targets not explicitly maintained by the bosh team. These include the following:

* OpenSuse
* PhotonOS
* Red Hat Enterprise Linux (RHEL)
* CentOS
* Ubuntu Trusty
* PowerPC

The work of removing support for these targets is currently happening on "wip/reduce-build-targets", with the goal of bringing it into the "master" branch. This only impacts forward development, and should not impact past branches. For any consumers of the above build targets, we'd love to hear from you in the #bosh-core-dev channel in Cloud Foundry slack.

We will continue cutting releases for ubuntu-xenial lines and centos 3763.x, per our standard support policy.

Context:
Feature work has been difficult on the bosh-linux-stemcell-builder repository as it's housed so much logic. Maintaining compatibility across all of the build targets has made stages (written in bash) very complicated. As we explore making bigger improvements to the builder, we're looking to lessen the builder's responsibility

- Aakash, bosh team
Re: Announcing cf-abacus end of life

Michael Maximilien
 

Thanks for the summary email and blog post Hristo and for all of your work and dedication to this project.

Like any projects, it had its heyday and moments of excitement. And now retirement.

I know at least one person indicated interest during the last CAB call, perhaps they will reach out.

In any case, many thanks again and happy holiday season. Best,

Max

On Tue, Nov 26, 2019 at 12:59 PM Hristo Iliev <hsiliev@...> wrote:
Hi cf-dev,

Abacus was started in 2015 by IBM with SAP joining shortly after. Since several years SAP is the only contributor, as it used Abacus in production.

Most users do not find the project robust and cost effective solution. Several reasons for this are outlined in this blog. We started solving some of the problems as part of version 2, but in the meantime our focus as a company has shifted.

As a result of all this, there is no activity around the project for more than a year, so we moved Abacus to the attic to reach its end of life.

If this still is a topic you are interested in, please reach out to us by replying to this mail or contacting me directly.

Best regards,
Hristo Iliev



--

Announcing cf-abacus end of life

Hristo Iliev
 

Hi cf-dev,

Abacus was started in 2015 by IBM with SAP joining shortly after. Since several years SAP is the only contributor, as it used Abacus in production.

Most users do not find the project robust and cost effective solution. Several reasons for this are outlined in this blog. We started solving some of the problems as part of version 2, but in the meantime our focus as a company has shifted.

As a result of all this, there is no activity around the project for more than a year, so we moved Abacus to the attic to reach its end of life.

If this still is a topic you are interested in, please reach out to us by replying to this mail or contacting me directly.

Best regards,
Hristo Iliev
Routing Release 0.195.0

Keshav Sharma <ksharma@...>
 

Hello CF community,

Release Highlights

  • Platform Operators can continue routing to applications and system components even during a control plane outage details

  • Application Developers can ensure that their Java apps communicate to the gorouter successfully and do not experience any error caused due to TLS1.3 details

Manifest Property Changes

JobProperty0.193.0 Default0.195.0 Default
gorouterrouter.prune_all_stale_routesdid not existfalse
goroutertls1.3did not existfalse

CF-Bosh Networking
Re: Networking - http ingress routing

Dr Nic Williams <drnicwilliams@...>
 

This is fabulous seeing some cf-on-k8s native functionality.

Nic
--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Networking - http ingress routing

Wa Gao
 

Hello cf-dev!


The cf-k8s-networking team ship a new feature leveraging Istio and Envoy technology that App Developer can rely on the platform to provide http ingress routing to the workload on Cloud Foundry running on Kubernetes details. 

 

Please reach out if you have any questions. Thanks.

 

Regards,


--

Wa Gao (Claire) | Senior Product Manager, Networking | Pivotal

Phone: 508-615-8644 | Email: wgao@...

 
581 - 600 of 9377