So I have two services A and B, and A needs to login to B via Oauth2. B is using is using Django OAuth Toolkit as its Oauth2 provider. Service A is also a Django app (not really important). We are introducing Spinnaker into our stack so that we can get unique staging environments (i.e. someUniqueString.staging.com) and remove the bottleneck of waiting for others to be done with staging before deploying to it.
The issue is that OAuth2 does not support wildcard subdomains in its callback URLs for security purposes. Is there a workaround for this or has anyone figured out how to combine Spinnaker and Oauth2? It would kinda defeat the purpose of all this automation if we had to go into the Django OAuth Toolkit after every staging deploy to add the generated URL to the list of callback URLs.
Related
I have tried the SCDF Security with UAA + LDAP example (link).
However, Im looking for some more Security approaches while using SCDF local. It 'll be great if having example (source, document)
It is not an official sample, but we have another full-blown UAA based end-to-end solution that works with local, and as well the other platform choices that we support.
See: jvalkeal/randomstuff/dataflow-uaa.
With this, you can run UAA as a standalone process served at 8080, and SCDF+Skipper running separately it can negotiate with and use the UAA backend for authentication/authorization flows. Feel free to customize the uaa.yaml with desired users, roles, and the associated scopes. Once again, all this is outside of SCDF, and it comes down to how much you'd want to rely on UAA like identity providers.
Keycloak is another excellent option for a local deployment experience. I believe there's a Docker image for Keycloak.
I have a React-based SPA that I'm trying to test against a versioned backend with its own Database.
In production, the part of the backend is exposed to the outside world via AWS services, like API Gateway. We also use DynamoDB for storing some API-level user details, and Cognito w/ User Pools for authentication. Calls are made to API Gateway, which after authenticating with a Key, makes VPC-link calls to the backend (all of our applications are in a private VPC). Here's a diagram illustrating the relationship:
This is fine when deployed, but I'd want to be able to reproduce this setup locally for development and testing purposes (not deployment). From the reading I was doing about AWS SAM, it seems like it might be the best tool for the job. But getting started with it has been difficult as I'm not sure what the relationship between all the methods/endpoints that I defined and individual Lambda functions that I have to define for SAM as part of my API.
I have a swagger template, so that should make things easier. But I'm not sure how to handle things like Proxying the calls to my backend, setting up authentication, etc. and the SAM documentation seems lacking in regards to this.
Anyone have any tips or experiences?
Many thanks!
I am trying to setup Spring Cloud Data Flow (SCDF) to run in Local mode and how few questions which may help me decide if its a suitable platform for my requirements.
Even though the recommendation is to use Cloud Foundry, Kubernetes etc as task execution environment my preference to run things on production is local mode mainly because I don't have a lot of workload and cant deal with all the additional complexity. Now in local mode will I be able to run all types of SCDF apps, namely Streams, Jobs and tasks with no limitations? Some parts of the document mentions that only Jobs can be run in local mode.
Security - I am looking to put controls in place around deployment of apps and operational access to the tool (dashboard) and do see the support for LDAP with roles as an option but the whole concept of using Cloudfoundry UAA, another product to drive the user managements seems like an overkill. Is there no way to configure the tool with an existing LDAP server? Found the following in one of the LDAP issues in Github but its not clear whether it uses UAA in its docker image. Worst case I wont mind if the dashboard can be run in a view/read only mode.
https://github.com/spring-cloud/spring-cloud-dataflow/issues/2871
If Spring Cloud Data Flow were a purely monolithic application, integrating all aspects of security directly into the app is definitely easier to to wrap one's mind around. This is how Spring Cloud Data Flow originally started out from a security perspective and thus, versions of Spring Cloud Dataflow <2.0.0 supported what we labelled traditional security.
However, even before 2.0.x Spring Cloud Data Flow:
Had to integrate with external platforms such as Cloud Foundry
Became more and more microservices oriented (e.g. by using Skipper)
As a result 2 parallel security architectures had emerged, one using traditional security and the other one driven by OAuth2/OpenID Connect.
This started to become increasingly harder to maintain and for 2.0.x we decided to exclusively focus on OAuth2/OpenID Connect. However, we still had to support a rich set of enterprise features such as Roles, LDAP integration etc. As such, we find that the open-source, production-ready CloudFoundry User Account and Authentication (UAA) Server is an excelling choice. Its LDAP support and features actually exceeds the features offered by Spring Cloud Dataflow <2.0.0.
So yes, in order to setup security for Spring Cloud Data Flow locally, you need to run the UAA. And the UAA would also provide the LDAP support. Technically, Spring Cloud Data Flow has no awareness of the LDAP setup at all.
I hope this provides some background regarding how the Spring Cloud Data Flow security architecture emerged. Please have a look at the reference documentation and the aforementioned SCDF Security with UAA + LDAP example. Don't hesitate to reach out in case of further questions!
Disclaimer: I am a committer on the project.
Starting from v2.0, we delegate to UAA for authentication and authorization. There are a variety of write-ups on this matter; a more comprehensive one to look at is the end-to-end sample on how all this could be put together locally. You do not need CF or K8s, all this can run locally also. We rely on UAA as the gateway to standardize on end-to-end SSO across all the client tools, including shell, dashboard, RESTful APIs, CTR, etc.,
Sample: SCDF Security with UAA + LDAP. For further reading, please refer to the security section in the ref. guide.
Lastly, we do not recommend Local for a production install, but I understand that resiliency and/or restartability of apps under failure condition is not a requirement for some workloads.
I am building a web application where development teams can install and use inside their companies. I am exploring the possibility of adding SSO support with Github since it is very convenient for developers.
In Github API, Auth0, Google etc. you need to specify Callback URLs.
The problem is that since everybody can deploy an instance of my application they can host it under any valid domain or just use a local ip address. So the Callback URLs cannot be predefined.
One option is to instruct people to deploy the app under certain local domains/subdomains. However, I don't think this is a good solution.
Do you know any other options that might solve my problem?
Is SSO only suitable for apps that run under global(already known) domains?
I'm going to be undertaking a large project for a client of mine. I need to write an IDP (identity provider) that will handle single-sign-on to multiple apps by a number of different authentication methods (such as SAML, OAuth, Form-based auth, HTTP Basic auth). I'd also need the ability to add in additional types of authentication as the app grows.
The basic idea would be that we'd have three different components to the app. One would be the IDP. Another would be a data-store that contains user accounts, the apps they want to use, etc. The third would be a GUI front-end that allows users to sign into apps.
It seems that there are some existing gems that handle authentication, like https://github.com/onelogin/ruby-saml and https://github.com/intridea/omniauth. My question is, am I overcomplicating this project -- would I just be able to use existing gems like these to act as the IDP, or is this a project where I'd need to read specs and implement them myself in Ruby?
Using something like SAML toolkit for Ruby on Rails adapted to work with ADFS server, you can integrate with ADFS. Now you can leverage ADFS features:
Interface with Facebook etc. via Azure ACS
Interface with Azure Active Directory and hence SSO to SaaS applications
Azure Active Directory Multi Factor Authentication
BYOD via the Web Applications Proxy
OAuth on ADFS 3.0
and so on. The list is expanding all the time.
Once you hook into these standards. you just inherit all the new features as they are released.