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.