1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
Re: KubeCF and Quarks – status and plans #cf

Dr Nic Williams <drnicwilliams@...>
 

If anyone is looking for a small example of a BOSH release with a Helm chart for Quarks deployment and README docs, I’ve got an example at:





On Thu, 19 Dec 2019 at 9:59 am, Troy Topnik <troy.topnik@...> wrote:
KubeCF (formerly the v3 branch of SUSE/scf) produces builds of CFAR which can be deployed to Kubernetes with Helm and managed by the cf-operator. Though this is currently in the SUSE namespace, the plan is to make this an upstream project under the Runtime PMC.  
 
KubeCF releases are passing CATS and we are on track for a 0.1.0 release of KubeCF this month, after which SUSE will transferring this repo to Cloud Foundry Foundation control.  
 
In other words, the Cloud Foundry *community* now has a CFAR distribution for Kubernetes that closely tracks cf-deployment.  
 
It exists. You can use it. If you work on a Runtime PMC project, KubeCF already consumes your BOSH release and packages it for Kubernetes.  
 
There has been a lot of discussion in the Kubernetes SIG meetings about how component teams should ultimately build truly "Kube-native" CFAR components which would not rely on BOSH or cf-operator.  Some teams have already started to refactor or rewrite their CFAR components to deliver Kubernetes artifacts (containers with Kubernetes YAML, YTT templates, or Helm charts).  
 
You don't have to do this in isolation! The members of the Quarks team have years of experience packaging CFAR for Kubernetes. They can be a great resource when making design decisions for your project, and are open to working with you. 
 
Though we want to ensure teams have a certain amount of freedom to create their releases with the tools of their choosing, these releases must eventually come together in a cohesive CFAR release that is deployable and manageable with tools familiar to the Kubernetes community. Right now, we use BOSH releases as the contract between individual components and cf-deployment releases. With KubeCF, you can optionally substitute Helm charts for BOSH releases, but this could be extended to support Kubernetes YAML or other templating mechanisms.  
 
So, if you're working on Kube-ifying your piece of CFAR, get in touch with the Quarks team on #quarks-dev and let them know how they can help, or how you could help! 
 
Thanks! 
 
SUSE Cloud Foundry Team 

--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Re: KubeCF and Quarks – status and plans #cf

Michael Maximilien
 

This is fantastic news,Troy and team. Thanks for sharing.

Ill contact you to see if a CAB presentation makes sense. Especially if a brief demo showing ease of deployment could be shown.

Slack you soon. Best,

Max


On Wed, Dec 18, 2019, 3:59 PM Troy Topnik <troy.topnik@...> wrote:
KubeCF (formerly the v3 branch of SUSE/scf) produces builds of CFAR which can be deployed to Kubernetes with Helm and managed by the cf-operator. Though this is currently in the SUSE namespace, the plan is to make this an upstream project under the Runtime PMC.  
 
KubeCF releases are passing CATS and we are on track for a 0.1.0 release of KubeCF this month, after which SUSE will transferring this repo to Cloud Foundry Foundation control.  
 
In other words, the Cloud Foundry *community* now has a CFAR distribution for Kubernetes that closely tracks cf-deployment.  
 
It exists. You can use it. If you work on a Runtime PMC project, KubeCF already consumes your BOSH release and packages it for Kubernetes.  
 
There has been a lot of discussion in the Kubernetes SIG meetings about how component teams should ultimately build truly "Kube-native" CFAR components which would not rely on BOSH or cf-operator.  Some teams have already started to refactor or rewrite their CFAR components to deliver Kubernetes artifacts (containers with Kubernetes YAML, YTT templates, or Helm charts).  
 
You don't have to do this in isolation! The members of the Quarks team have years of experience packaging CFAR for Kubernetes. They can be a great resource when making design decisions for your project, and are open to working with you. 
 
Though we want to ensure teams have a certain amount of freedom to create their releases with the tools of their choosing, these releases must eventually come together in a cohesive CFAR release that is deployable and manageable with tools familiar to the Kubernetes community. Right now, we use BOSH releases as the contract between individual components and cf-deployment releases. With KubeCF, you can optionally substitute Helm charts for BOSH releases, but this could be extended to support Kubernetes YAML or other templating mechanisms.  
 
So, if you're working on Kube-ifying your piece of CFAR, get in touch with the Quarks team on #quarks-dev and let them know how they can help, or how you could help! 
 
Thanks! 
 
SUSE Cloud Foundry Team 
KubeCF and Quarks – status and plans #cf

Troy Topnik
 

KubeCF (formerly the v3 branch of SUSE/scf) produces builds of CFAR which can be deployed to Kubernetes with Helm and managed by the cf-operator. Though this is currently in the SUSE namespace, the plan is to make this an upstream project under the Runtime PMC.  
 
KubeCF releases are passing CATS and we are on track for a 0.1.0 release of KubeCF this month, after which SUSE will transferring this repo to Cloud Foundry Foundation control.  
 
In other words, the Cloud Foundry *community* now has a CFAR distribution for Kubernetes that closely tracks cf-deployment.  
 
It exists. You can use it. If you work on a Runtime PMC project, KubeCF already consumes your BOSH release and packages it for Kubernetes.  
 
There has been a lot of discussion in the Kubernetes SIG meetings about how component teams should ultimately build truly "Kube-native" CFAR components which would not rely on BOSH or cf-operator.  Some teams have already started to refactor or rewrite their CFAR components to deliver Kubernetes artifacts (containers with Kubernetes YAML, YTT templates, or Helm charts).  
 
You don't have to do this in isolation! The members of the Quarks team have years of experience packaging CFAR for Kubernetes. They can be a great resource when making design decisions for your project, and are open to working with you. 
 
Though we want to ensure teams have a certain amount of freedom to create their releases with the tools of their choosing, these releases must eventually come together in a cohesive CFAR release that is deployable and manageable with tools familiar to the Kubernetes community. Right now, we use BOSH releases as the contract between individual components and cf-deployment releases. With KubeCF, you can optionally substitute Helm charts for BOSH releases, but this could be extended to support Kubernetes YAML or other templating mechanisms.  
 
So, if you're working on Kube-ifying your piece of CFAR, get in touch with the Quarks team on #quarks-dev and let them know how they can help, or how you could help! 
 
Thanks! 
 
SUSE Cloud Foundry Team 
FW: From the Desk of the Executive Director - December 2019

Swarna Podila
 

Hi Everyone,

As Abby shared in the update from “Desk of the Executive Director” here, Cloud Foundry Summits in 2020 will be slightly different.

 

Cloud Foundry Summits in 2020 will be collocated with Open Source Summit in North America (Austin, TX in June) and Europe (Dublin, Ireland in October) and will be hosted as a one-day event at both of these locations.  The Summits will have breakout sessions, Diversity Luncheon, User Day, and Contributor Summit.  Please stay tuned for additional details (CFP, registration, sponsorship, unconference, etc.).

 

If your organization is a Cloud Foundry Foundation member, you can join the AMA call tomorrow (Dec 17 at 8AM US Pacific; see zoom info in Abby’s email below) and get any/all of your Summit-related question answered.  If you would like to submit a question prior to the call, please do so here.  We will make sure your question is answered.

 

If you have any questions, please do not hesitate to reach out to us via email or slack.

-- ​Swarna Podila (she/her)

​Senior Director​, Community​ | Cloud Foundry Foundation

​spodila@...

@​skpodila​

You can read more about pronouns here, or please ask if you'd like to find out more.

 

 

From: "Abby Kearns, Executive Director Cloud Foundry" <akearns@...>
Reply-To: "Abby Kearns, Executive Director Cloud Foundry" <akearns@...>
Date: Monday, December 16, 2019 at 6:59 AM
To: "spodila@..." <spodila@...>
Subject: From the Desk of the Executive Director - December 2019

 

Foundation updates from Executive Director Abby Kearns

We’re ending one chapter and beginning another soon: 2020 is not just a new year but a new decade. The Foundation will be closed December 23rd through January 5th, so please reach out to me or our team if you need anything beforehand. I wish you the most pleasant holiday season.

Cloud Foundry Events in 2020
In 2020, we will be revamping our events strategy to ensure we continue to meet the needs of our community. We are purposely limiting the size and scope of our Summits to better serve contributors and end users with content tailored to their specific needs. 

Cloud Foundry Summits will be one-day events co-located with Open Source Summits in North America and Europe to provide visibility and engagement with broader open source communities, including the larger Linux universe. These more intimate events will enable our committed community of contributors and end users to get together to foster collaboration, share best practices, and have lively discussions.

In addition to Summits, we will rely on our strong member and end user community to host Cloud Foundry Days around the world. We encourage Cloud Foundry Day organizers to reach out to enterprise developers who are not yet Cloud Foundry users and facilitate more opportunities for connection within our global community. We will be supporting this effort by rolling out an updated CF Days Kit in early 2020 to your marketing teams.

Members Only!

  • Ask Me Anything: Our last AMA of 2019 is tomorrow, Tuesday, December 17th at 8:00 AM PST. Join my Zoom to discuss what the future holds for Cloud Foundry.

A Few Articles Worth Sharing

 

Happy Holidays to all of you and see you in 2020!
 

Abby Kearns

Executive Director | Cloud Foundry Foundation

Facebook

 

Twitter

 

Website






This email was sent to spodila@...
why did I get this?    unsubscribe from this list    update subscription preferences
Cloud Foundry · One Letterman Drive Building D · Suite D4700 · San Francisco, CA 94129 · USA

Email Marketing Powered by Mailchimp

[Proposal] CAPI V3 Service Offerings and Service Plans

George Blue
 

Hello everyone,

The Services API Team has been working on a model for the Cloud Controller V3 API for service offerings and service plans.
You can view the proposals here:


We are seeking feedback over the next month from the community to help us finalize this proposal and move forward with implementation in the New Year.

We are looking forward to your comments! You can contact us by replying to this email, via mail to cf-services-api@... or in our cloud foundry slack channel #svat 

Best regards
George and Marcela
On Behalf of the Services API Team
CF CAB 2019 Survey

Michael Maximilien
 

Hi, all,
 
Please spare 5 minutes (might be even less) to take this 4 questions survey to help shape Cloud Foundry and the Community Advisory Board (CAB) calls and organization in 2020.
 
 
 
I plan to close this on January 14th and present the results at the January 15th CAB call.
 
Thanks for your time. Best,

------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
CAB call for December 2019 - CANCELED

Michael Maximilien
 

Hi, all,
 
As per discussions in last CAB call, we are canceling the last one of the year (scheduled next week) since it's so close to the year end holidays. We will reconvene on January 15th where we have one scheduled talk:
 
1. CF Smoke Tests by Onno Brouwer of Rijkswaterstaat [1][2][3]
 
-----
If you have a talk to share then please contact me ASAP (here or Slack).
 
I will also be sending (separate email next week) the survey for 2019. Please look out for this.
 
All the best,
CFP tracker and #jobs on CF Slack #jobs

Swarna Podila
 

Hi Everyone, please note:

  1. I’ve shared a spreadsheet on CF Slack with a list of tech conferences, dates, and CFP deadlines, etc. I’ll be adding more to the list as I learn about other conferences; so please check in often. I’ve pinned the post to the slack channel so folks can find it easily.
  2. Please do check the posts/updates in #jobs channel in CF Slack; whether for yourself or for a friend.  And please feel free to share those in your social networks.

 

Thank you!

-- ​Swarna Podila (she/her)

​Senior Director​, Community​ | Cloud Foundry Foundation

​spodila@...

@​skpodila​

You can read more about pronouns here, or please ask if you'd like to find out more.

 
Re: [EXTERNAL MESSAGE] Re: [cf-dev] Using SAML 2 Bearer token with our own UAA Server #uaa

Shetty, Viraj S [CTR]
 

Thanks.

The SAML assertion generated by ADFS contains "https://<HIDDEN>/saml/SSO/alias/cloudfoundry-saml-login-dev" while the bearer assertion in the metadata file is https://<HIDDEN>/oauth/token/alias/cloudfoundry-saml-login-dev (this is what i am using to post). 

This raises another question. In a general case, lets say Application A is an on-prem application which is already SAML authenticated with internal ADFS Server using a Relying Party R. Web Service W (OAuth Resource Server) is located in cloud.gov and is a client for UAA in cloud.gov. The UAA in cloud.gov has a trust with the same internal ADFS, however the Relying Party is different (That would be the most likely scenario). In this case, the SAML assertion will contain the recipient field pointing to application A (and will not point to UAA). How would this even work ? Sounds like the assertion would be rejected by the UAA if we pass to UAA to get oauth token. 
Re: [EXTERNAL MESSAGE] Re: [cf-dev] Using SAML 2 Bearer token with our own UAA Server #uaa

Filip Hanik
 

probably https:// and not http://
Re: [EXTERNAL MESSAGE] Re: [cf-dev] Using SAML 2 Bearer token with our own UAA Server #uaa

Filip Hanik
 

See that the recipient matches with https://<HIDDEN>/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 ?) .

It's been a while since I dug into that code, but I think the Recipient should match the URL you're posting the message to, which is:

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

Filip
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
581 - 600 of 9388