1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
Reset password : if the unregistered email address entered then also giving success message. #cf #uaa

shilpa kulkarni
 

Hi,
 
If I pass email id (which is not registered)for reset password link  then it should give error message but it is giving success message only. I am not getting where to change that code.
Can anyone please provide solution for this?
 
Thanks & Regards
Shilpa
Route integrity on Windows

Aaron Huber
 

We have been waiting for some time for a solution for route integrity support on Windows and I wanted to check on the status and compare notes on what others are doing.

 

We are still using the Windows 2012 R2 stack because we require IPSec encryption of the HTTP traffic between the router and the instance.  Overall CF has made great progress on removing all non-encrypted traffic across the platform and the last two places where encryption is missing are nats which is finally underway, and route integrity on Windows.  Once we close those two gaps we’ll finally be able to stop using IPSec on the platform, but until then, since Windows 2019 still doesn’t support IPSec along with NAT in containers, we are stuck with the older stack.

 

There are a few options that we know of:

 

  • Use the experimental route integrity ops file using Nginx instead of envoy – is anyone using this successfully in production?
  • Wait for Envoy support on Windows – this has been in progress for a while and Microsoft still seems to be actively working on it, but once it becomes available will support for it be added to Cloud Foundry?
  • Wait for Kubernetes support to be fully production ready – hopefully the new platform will be fully encrypted from the beginning

 

What are other platform operators that offer Windows support doing for now?

 

 

Aaron Huber

Intel Corporation
Reminder: CAB call on Wednesday, June 17 @ 8AM PDT / 11AM EDT / 5PM CEST

Troy Topnik
 

Please join us for this month's Community Advisory Board call!

We'll have James Hunt from Stark & Wayne telling us all about managing BOSH from Kubernetes with Gluon:

 https://github.com/starkandwayne/gluon

... along with the regular community updates from the PMC leads and community Q&A. Here's the agenda:

https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit#

And the chat room: slack.cloudfoundry.org - join the #cab channel Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/757994996 Or iPhone one-tap : US: +16468769923,,757994996# or +16699006833,,757994996# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 876 9923 or +1 669 900 6833 or +1 408 638 0968 Meeting ID: 757 994 996 International numbers available: https://zoom.us/zoomconference?m=BbM_MZowkH08pdKycQk10at13V5cLneM
Hope to see you there!

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
troy.topnik@...
 
Proposal to retire the Perm project in the App Runtime PMC

Eric Malm
 

Hi, everyone,

I'm proposing to retire the incubating Perm project in the App Runtime PMC and to move its associated repos to the cloudfoundry-attic GitHub organization. We will plan to discuss and approve the proposal at the June 23rd App Runtime PMC meeting.

For context, the Perm project started in 2017 with the goal of providing a general authorization service for Cloud Foundry that could absorb and extend the authorization roles currently encoded in Cloud Controller. On account of difficulties integrating with the v2 Cloud Controller API, the project was placed on hiatus in late 2018, where it has remained to date. Although making authorization in the Cloud Foundry App Runtime more flexible and independent of existing components remains an important goal for the project, continual evolution in the identity space and the ongoing transition of the App Runtime to Kubernetes make it likely that any new efforts to achieve that goal will rely more directly on other community projects and technologies, such as the Open Policy Agent or Kubernetes RBAC itself.

Thanks,
Eric Malm, App Runtime PMC Lead
CF-K8s-Networking v0.2.0

Keshav Sharma <sharmake@...>
 

Hi cf-dev,

CF-K8s-Networking-Release v0.2.0 has been cut!

Release Highlight

  • Platform Operator can verify that cf-for-k8s leverages Istio 1.6.x version details



What was included in CF-K8s-Networking-Release v0.1.0?

Release Highlights

Basic Ingress Routing:

  • Alana can confirm that Istio objects and Services describing CC Routes are represented in the K8s API details
  • Cody can confirm that an application on cf-for-k8s is accessible to end users via basic HTTP routing details
  • Cody can map/create routes that have FQDNs that are longer than 63 characters details
  • Cody can confirm that wildcard routes get successfully created on cf-for-k8s details
  • Cody can confirm that ingress TLS is configured for the “default” app domain for a vanilla installation of cf-for-k8s details

Securing app and system component communications:

  • Alana can confirm that all communication between metacontroller and route syncer are encrypted and mutually authenticated (via sidecars) details
  • Alana can confirm that connections between istio control- plane components are encrypted details
  • Cody can confirm that ensure that all communications between system components and between apps are encrypted and mutually authenticated (via sidecars) details

Exposing networking sub-system metrics:

  • Alana can identify memory usage of ingress router by looking at metrics details
  • Alana can use prometheus to see details such as number of http, and tcp connections being made by the incoming traffic details
  • Alana can confirm that envoy is receiving up-to-date information from istio control plane details

CF-K8s Networking
Reset password : if the unregistered email address entered then also giving success message. #cf

shilpa kulkarni
 

Hi,

If I pass email id (which is not registered)for reset password link  then it should give error message but it is giving success message only. I am not getting where to change that code.
Can anyone please provide solution for this?

Thanks & Regards
Shilpa
Re: Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

David McClure
 

Jonathan is correct. 

This issue applies whether or not the reverse proxy is a route service. In fact, while the reproduction steps in the original post used a route service, later in the issue, the original poster indicates that the use case they care about solving for currently is using nginx as the reverse proxy (not as a route service).

And yes, I believe it also applies if the proxy and the backend are deployed on two different CF's (though that is not what we care about now, so if a solution cut that out of scope, I think it'd be fine).

In any case, I think the issue title feels OK still given the above, but thanks for asking the question and giving us a chance to clarify!

From: cf-dev@... <cf-dev@...> on behalf of Jonathan Matthews via lists.cloudfoundry.org <contact+cfdev=jpluscplusm.com@...>
Sent: Tuesday, June 9, 2020 2:37 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response
 
Marco,

I’ve no extra information on this than this thread, but it strikes me that it’s definitely possible to deploy apps to CF which would reverse proxy other apps on CF, *without* attaching them as route services. 

I think it might be a interesting and potentially sub-optimal choice to do so, given route services are essentially reverse-proxy-as-a-service(!), but I can definitely see folks doing that. Perhaps with workflows baked in from before route services were a thing. 

Overall I’d suggest the framing of this should reference the hosting of both the proxy and the origin service: AIUI both have to be on CF for this thread’s problem and solution to be in scope. They can be *different* CF installations, however, if I’ve got it correct in my head ...

“Reverse proxy applications which are called by a gorouter, and which themselves call a gourouter”? Hmmm. Perhaps a bit too wordy ...

HTH,
Jonathan

On Tue, 9 Jun 2020 at 08:47, Marco Voelz <marco.voelz@...> wrote:

Dear David,

 

Thanks for the detailed explanations and the heads-up! While looking at the initial issue in github, I noticed that there's a mismatch in vocabulary between the OP and your team responding: My understanding is this change impacts route service, as they are known to the Cloud Controller, it does not impact any generic setup where people deploy a reverse proxy application and forward from there the requests to individual CF applications. Is this an accurate summary?

 

In this case, I'd like to see this reflected in the language for the issue/backlog item: only scope this to cf route services, not "cf deployed reverse proxy applications".

 

In case this influences also reverse proxy applications deployed with other means than route services, I'd need to ping some internal teams to assess the impact of this from their point of view.

--
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html
Re: Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

Jonathan Matthews <contact+cfdev@...>
 

Marco,

I’ve no extra information on this than this thread, but it strikes me that it’s definitely possible to deploy apps to CF which would reverse proxy other apps on CF, *without* attaching them as route services. 

I think it might be a interesting and potentially sub-optimal choice to do so, given route services are essentially reverse-proxy-as-a-service(!), but I can definitely see folks doing that. Perhaps with workflows baked in from before route services were a thing. 

Overall I’d suggest the framing of this should reference the hosting of both the proxy and the origin service: AIUI both have to be on CF for this thread’s problem and solution to be in scope. They can be *different* CF installations, however, if I’ve got it correct in my head ...

“Reverse proxy applications which are called by a gorouter, and which themselves call a gourouter”? Hmmm. Perhaps a bit too wordy ...

HTH,
Jonathan

On Tue, 9 Jun 2020 at 08:47, Marco Voelz <marco.voelz@...> wrote:

Dear David,

 

Thanks for the detailed explanations and the heads-up! While looking at the initial issue in github, I noticed that there's a mismatch in vocabulary between the OP and your team responding: My understanding is this change impacts route service, as they are known to the Cloud Controller, it does not impact any generic setup where people deploy a reverse proxy application and forward from there the requests to individual CF applications. Is this an accurate summary?

 

In this case, I'd like to see this reflected in the language for the issue/backlog item: only scope this to cf route services, not "cf deployed reverse proxy applications".

 

In case this influences also reverse proxy applications deployed with other means than route services, I'd need to ping some internal teams to assess the impact of this from their point of view.

--
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html
Re: Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

Marco Voelz
 

Dear David,

 

Thanks for the detailed explanations and the heads-up! While looking at the initial issue in github, I noticed that there's a mismatch in vocabulary between the OP and your team responding: My understanding is this change impacts route service, as they are known to the Cloud Controller, it does not impact any generic setup where people deploy a reverse proxy application and forward from there the requests to individual CF applications. Is this an accurate summary?

 

In this case, I'd like to see this reflected in the language for the issue/backlog item: only scope this to cf route services, not "cf deployed reverse proxy applications".

 

In case this influences also reverse proxy applications deployed with other means than route services, I'd need to ping some internal teams to assess the impact of this from their point of view.

 

Thanks and warm regards

Marco

 

From: <cf-dev@...> on behalf of David McClure <dmcclure@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Friday, 5. June 2020 at 19:19
To: "cf-dev@..." <cf-dev@...>
Subject: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

 

Hi all,

 

Recently, the following feature request was made for gorouter:

 

 

The suggestion for implementing this feature in gorouter is relatively simple and we have validated that it works: If the request includes a VCAP_ID cookie, then always include a VCAP_ID in the response.

 

While the cookie in the response is redundant in most cases, we think this is a reasonable change to make. It would only impact applications that use sticky sessions.

 

That said, we wanted to bring this up to a wider audience before proceeding. Please respond here or on the issue if you can share any reasons why we should not make this change.

 

 

Additional background:

 

Currently, when an application sets a cookie that matches one of the sticky session cookie names configured for gorouter, the gorouter will add an additional Set-Cookie header with the name __VCAP_ID__ with the value being the instance ID of the backend that handled that request. On subsequent requests, as the client includes this cookie in the request, the gorouter will route the request to the same instance. If it succeeds, it does not include the instance ID in the response (as this was assumed to be redundant information). The only exceptions currently are 1) if the backend sets the session cookie (most don't do this in every response for the same reason - it's usually redundant), or 2) if the backend instance was not found (e.g. because that instance failed or was rescheduled to another cell).

 

The current implementation described above works in most cases, but fails in the following way when there is a cf-deployed proxy in front of the backend.

 

In that case, the request path looks like this:

 

client -> gorouter -> proxy -> gorouter -> backend

 

In this scenario, the first gorouter in front of the proxy fails to find the instance ID of the backend, as it only looks for instances of proxy. Because it fails to match, in its response, it sets the cookie to an instance of the proxy app instead, and the subsequent request gets routed to a random backend. It ends up in a pattern where 2 requests go to the same backend at a time, and then flipping to a different one.

 

A workaround in the current implementation of the gorouter is to always have the backend application set the session cookie. This works, but requires changes to application code.

 

 

 

Thanks!

Dave

 

Engineer on #networking

 

 

 

 
Re: Seeking Nominations: Cloud Foundry Extensions PMC

Chip Childers <cchilders@...>
 

This sounds great, and aligns with how Dr Max combined running the CAB calls and leading the Extensions PMC. I'll leave this until EOD today, and then start a vote within the PMC.

Chip Childers
Executive Director
Cloud Foundry Foundation



On Thu, Jun 4, 2020 6:45 PM, Neil MacDougall NMacDougall@... wrote:

All,

 

I believe we are still seeking nominations for the extensions PMC.

 

I’d like to nominate Troy Topnik from SUSE – he has a passion for Cloud Foundry that would serve the extensions PMC well.

 

Regards,

 

Neil

 

From: Swarna Podila <spodila@...>
Date: Thursday, 7 May 2020 at 00:57
To: CF Developers Mailing List <cf-dev@...>, cf-extensions-pmc <cf-extensions-pmc@...>, Michael Maximilien <maxim@...>
Subject: Re: Seeking Nominations: Cloud Foundry Extensions PMC

 

Hi Everyone,

Just a quick reminder to send us your nominations by the end of Friday (May 8).

 

Cheers!

 

-- Swarna Podila (she/her)

Senior

 Director

, Community

 | Cloud Foundry Foundation

 

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

 

 

On Thu, Apr 30, 2020 at 4:30 PM Swarna Podila <spodila@...> wrote:

Hi All,

You may have seen Dr. Max's note earlier.  After leading Extensions PMC for almost four years, he would like to step down and make space for new folks to take on the role. 

 

Please send in your nominations for a new lead for Cloud Foundry Extensions PMC by the end of day next Friday, May 8, 2020. 

 

-- Swarna Podila (she/her)

Senior

 Director

, Community

 | Cloud Foundry Foundation

 

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

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/CAPYQVGLQO3vLjyQ-YKvPWV8nWmf_40tndAB_Tg3WC5WaepAh%3DA%40mail.gmail.com.
Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

David McClure
 

Hi all,

Recently, the following feature request was made for gorouter:


The suggestion for implementing this feature in gorouter is relatively simple and we have validated that it works: If the request includes a VCAP_ID cookie, then always include a VCAP_ID in the response.

While the cookie in the response is redundant in most cases, we think this is a reasonable change to make. It would only impact applications that use sticky sessions.

That said, we wanted to bring this up to a wider audience before proceeding. Please respond here or on the issue if you can share any reasons why we should not make this change.


Additional background:

Currently, when an application sets a cookie that matches one of the sticky session cookie names configured for gorouter, the gorouter will add an additional Set-Cookie header with the name __VCAP_ID__ with the value being the instance ID of the backend that handled that request. On subsequent requests, as the client includes this cookie in the request, the gorouter will route the request to the same instance. If it succeeds, it does not include the instance ID in the response (as this was assumed to be redundant information). The only exceptions currently are 1) if the backend sets the session cookie (most don't do this in every response for the same reason - it's usually redundant), or 2) if the backend instance was not found (e.g. because that instance failed or was rescheduled to another cell).

The current implementation described above works in most cases, but fails in the following way when there is a cf-deployed proxy in front of the backend.

In that case, the request path looks like this:

client -> gorouter -> proxy -> gorouter -> backend

In this scenario, the first gorouter in front of the proxy fails to find the instance ID of the backend, as it only looks for instances of proxy. Because it fails to match, in its response, it sets the cookie to an instance of the proxy app instead, and the subsequent request gets routed to a random backend. It ends up in a pattern where 2 requests go to the same backend at a time, and then flipping to a different one.

A workaround in the current implementation of the gorouter is to always have the backend application set the session cookie. This works, but requires changes to application code.



Thanks!

Dave

Engineer on #networking
Is SAML configuration optional in UAA? #uaa

Enrique Cano
 

Hi

If we don't need to use the SAML protocol with UAA, do we really need to configure that section e.g. encryption keys? It seems UAA won't start if that section is empty.

Thanks
Enrique
cf-for-k8s 0.3.0 alpha release

Saikiran Yerram <syerram@...>
 

Hello CF community,

 

We just shipped cf-for-k8s 0.3.0 alpha release.

 

Feedback Survey

We would love to hear from the CF community on your experience with cf-for-k8s. Your feedback helps us improve our product and processes. Please take a moment to submit your feedback with this survey. Thanks in advance!

Notable changes since the last (v0.2.0) release

New features and Bug fixes

  • 🔥 Platform operators can now set ingress certs for cf apps using the new property workloads_certificate. 🔥
    • By separating certificate properties for CF API domain (system_certificate), app domains (workloads_certificate), and internal system components (internal_certificate), operators get granular control in creating certificates for different domains.
  • Resolved an issue when upgrading the internal Minio blobstore to new versions (Issue #164).
  • Resolved an issue when upgrading the internal Postgres database (Bitnami Postgres helm chart) (Issue #212). Please note that kapp exits [1] before the Postgres statefulset is available. In addition, rotating database passwords on an existing install do not currently work.
  • Platform operators can now install cf-for-k8s on Kubernetes 1.18 version. You can follow the newest (1.18) and the oldest version (1.14) changes by watching supported_k8s_versions.yml file.
  • Platform operators and app developers can see metrics after pushing the app using the cf cli v7 rolling strategy (Issue #177).
  • Platform operators will now get an error message if the kapp CLI version does not meet the minimum kapp version required to install cf-for-k8s. (This was already the case for vendir and ytt.)
  • Platform operators should see a reduction in insufficient CPU errors when installing cf-for-k8s (Issue #103). With PriorityClass for DaemonSet, K8s will schedule DaemonSet first before scheduling pods.
  • Platform operators can now consume Istio pilot metrics.
  • App Developers can pass environment variables with cf push (Issue #163).

[1] This is a known issue. You will have to manually check for the statefulset pod health before running cf-cli commands.

Other updates

  • CAPI now includes API readiness configuration, so that it can receive traffic only when it’s ready to accept.
  • Changed prefix for user-facing CAPI names to "cf-api".

What we are working on next

  • Continue to resolve issues pertaining to cf-for-k8s upgradability. With v0.3.0 release, Operators can now upgrade Minio, PostgresDB, and config-maps changes. Our next milestone is to resolve upgrade issues with system components, K8s cluster version, and 3rd party components.
  • Incorporate the full set of Paketo Cloud Native Buildpacks into cf-for-k8s.
  • Collaborate with contributing projects in establishing a workflow on consuming releases.

Have a question, reach out to us

Our slack channels

Interested in contributing?

  • The easiest way to get involved is to start attending the SIG meetings, join the #cf-for-k8s slack channel, and subscribe to the cf-dev@... mailing list.
  • You can also start by improving the docs. Install cf-for-k8s using the deploy docs and if you notice issues or discrepancies in the docs, you can submit a PR.

 
Re: Seeking Nominations: Cloud Foundry Extensions PMC

Neil MacDougall <NMacDougall@...>
 

All,

 

I believe we are still seeking nominations for the extensions PMC.

 

I’d like to nominate Troy Topnik from SUSE – he has a passion for Cloud Foundry that would serve the extensions PMC well.

 

Regards,

 

Neil

 

From: Swarna Podila <spodila@...>
Date: Thursday, 7 May 2020 at 00:57
To: CF Developers Mailing List <cf-dev@...>, cf-extensions-pmc <cf-extensions-pmc@...>, Michael Maximilien <maxim@...>
Subject: Re: Seeking Nominations: Cloud Foundry Extensions PMC

 

Hi Everyone,

Just a quick reminder to send us your nominations by the end of Friday (May 8).

 

Cheers!

 

-- Swarna Podila (she/her)

Senior

 Director

, Community

 | Cloud Foundry Foundation

 

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

 

 

On Thu, Apr 30, 2020 at 4:30 PM Swarna Podila <spodila@...> wrote:

Hi All,

You may have seen Dr. Max's note earlier.  After leading Extensions PMC for almost four years, he would like to step down and make space for new folks to take on the role. 

 

Please send in your nominations for a new lead for Cloud Foundry Extensions PMC by the end of day next Friday, May 8, 2020. 

 

-- Swarna Podila (she/her)

Senior

 Director

, Community

 | Cloud Foundry Foundation

 

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

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/CAPYQVGLQO3vLjyQ-YKvPWV8nWmf_40tndAB_Tg3WC5WaepAh%3DA%40mail.gmail.com.
Cloud Foundry Community Award Nomination Form

Paige O'Connor <poconnor@...>
 

Google Forms
Having trouble viewing or submitting this form?
Fill out in Google Forms
I've invited you to fill out a form:
Cloud Foundry Community Award Nomination Form
Please nominate individuals and/or teams from our community for the bi-annual Cloud Foundry Community Awards. These Awards recognize and appreciate contributions from the individuals in the CF community and will be presented at NA Summit.
    Email address *
    Categories *
    Committed Contributor Awesome Advocate Inspirational User
    Name of Nominee *
    Give us brief insight into why you nominated this individual and/ or team. *
This form was created inside of Cloud Foundry.
Report Abuse - Terms of Service - Additional Terms
Create your own Google Form
Re: Routing Release 0.201.0

Amelia Downs
 

*golang 1.14.4

Sadly, we are not living in some great post-pandemic future.

From: Amelia Downs
Sent: Tuesday, June 2, 2020 10:13 AM
To: cf-dev@... <cf-dev@...>
Subject: Routing Release 0.201.0
 

Hello cf-dev,

Routing Release 0.201.0 has been cut! It's an exciting one.


Release Highlights

  • Bump to golang 2.14.4
  • Bug Fix: Updated the logic for configuring drain timeout so that it always uses the value that is configured. There should not be a magic value (60) that it ignores and uses request_timeout instead.


Enjoy!
CF-Bosh Networking Team
Routing Release 0.201.0

Amelia Downs <adowns@...>
 

Hello cf-dev,

Routing Release 0.201.0 has been cut! It's an exciting one.


Release Highlights

  • Bump to golang 2.14.4
  • Bug Fix: Updated the logic for configuring drain timeout so that it always uses the value that is configured. There should not be a magic value (60) that it ignores and uses request_timeout instead.


Enjoy!
CF-Bosh Networking Team
How do we get the user attributes from AD into the ID Token ?

Shetty, Viraj S [CTR]
 

Hi Martijn –

 

Thank you for the response an pointers. I missed the fact that the attribute in the uaa.yml should be of the format

 

user.attribute.<attr_name>

 
Everything is working now. 

Thanks,

Viraj

 
Re: #uaa #uaa

Martijn de Boer
 

You need to set e.g. the config.attributeMappings['user.attribute.department'] attribute in the identity provider registration. See https://docs.cloudfoundry.org/api/uaa/version/74.18.0/index.html#oauth-oidc

Then you can retrieve it from the userinfo endpoint, see https://docs.cloudfoundry.org/api/uaa/version/74.18.0/index.html#user-info


config.attributeMappings['user.attribute.department'] String Optional Map external attribute to UAA recognized mappings. Mapping should be of the format user.attribute.<attribute_name>. department is used in the documentation as an example attribute.
Am 22.05.20 um 19:42 schrieb Shetty, Viraj S [CTR] via lists.cloudfoundry.org:

We have our own UAA server running in a cloud.gov environment which we use for all applications that are deployed in cloud.gov. These applications use OAuth 2 to integrate with the UAA server and the UAA server is using SAML to integrate with our on premises ADFS Identity Server. Currently the only claims that we are getting from ADFS are the standard First name, last name, email. But now one of the applications need a custom claim from the AD. We set that in ADFS and we now see the custom claim as part of the SAML but we dont see that in the ID token after a user login. What do I need to do in the UAA.yml to get this in the ID token ? I added an entry in the attributes mapping but it did not work.  Is there anything I need to add to the scopes for this to happen ? Whats the best way ? Any help is appreciated. 

       attributeMappings:
          somename: claim_url

#uaa #uaa

Shetty, Viraj S [CTR]
 

We have our own UAA server running in a cloud.gov environment which we use for all applications that are deployed in cloud.gov. These applications use OAuth 2 to integrate with the UAA server and the UAA server is using SAML to integrate with our on premises ADFS Identity Server. Currently the only claims that we are getting from ADFS are the standard First name, last name, email. But now one of the applications need a custom claim from the AD. We set that in ADFS and we now see the custom claim as part of the SAML but we dont see that in the ID token after a user login. What do I need to do in the UAA.yml to get this in the ID token ? I added an entry in the attributes mapping but it did not work.  Is there anything I need to add to the scopes for this to happen ? Whats the best way ? Any help is appreciated. 

       attributeMappings:
          somename: claim_url
401 - 420 of 9432