Are there near-term plans to incorporate LDAP authentication into Spinnaker and incorporate role-based access controls throughout the platform? Specifically, we would like to be able to control through our existing LDAP groups who can provision servers, security groups, applications, etc; also control the human approval step in a pipeline to restrict that to specific users on a per-pipeline level...really we're looking for the granularity of IAM roles in AWS (or the ability to leverage existing IAM roles)
Spinnaker supports configurable authentication via SAML at the API layer. All the services behind the API layer would typically be protected via HTTPS client auth and only directly callable by other Spinnaker services.
The current authentication model in Spinnaker is only based around restricting modifications to specific accounts (A Spinnaker installation can manage multiple accounts across multiple cloud providers). An account can be configured with a requiredGroupMemberships in which case, the authenticated user must be a member of the group (as provided by the SAML authentication configuration) in order to be able to mutate that account (new deploys, load balancers, security groups).
We don't currently have plans for anything more fine grained than that.
Here is a great writeup of how to enable SAML auth in Spinnaker
Related
We are building an application where the content i.e. data and files would need granular user access the way role and policy works. We use oAuth2 and OpenID connect using one identity provider.
My question is about the possibility of leveraging a platform or AWS Cloud service where this type of granular authorization is available. I don't want to build custom authorization matrix within my application, rather I prefer to use an API of a service and user role/policy for further actions.
When it comes to using scopes from OpenID connect, they are more suitable for defining API level of access.
I would start with your requirements, such as users only being able to only see their own data. Fine grained authorization is typically managed via claims in tokens, which can be highly dynamic when required.
See this Claims Best Practices article for some details. It mentions some specialist authorization systems also.
Cloud solutions may at times be more focused on infrastructure security whereas OAuth deals with application and user level security.
Having said that, defining resource policies as JSON documents like AWS does could be a useful declarative technique to complement claims. At runtime you could then compare a claim from a token, eg a role, against the resource policy to see if the user should be granted access.
We are planning to setup three applications, two of them are based on WordPress, and third one is based on Magento. We will deploy these three apps on AWS. We are looking for a tool to centralize the management of all the users for these three apps. We could grant different privilege and allow the different users have different right to these three apps. So, we should choose AWS Cognito or SSO?
You can use both if you go with cognito route. Cognito User pools handles your user management (registration, login, granting tokens) while Cognito Identity Pool lets you use any of the identity providers including user pool to exchange tokens for temporary aws credentials based on what role you have attached to the group of users.
Identity pools also accept SSO with 3rd part authentication providers (federated identity). You can sign in users on your user pool using social identity providers (facebook, google, amazon) or create one using Auth0.
AWS Cognito is the right fit for your application. AWS SSO is essentially a layer between active directories and services like Cognito or Firebase. AWS SSO helps in delegating access to AWS services and provides SAML/Oauth gateways connected to the active directories.
AWS Cognito on the other hand, allows you to easily integrate your login systems with any auth providers like AWS SSO, Okta, Auth0 and social media channels too. Hence, definitely considering your requirements, AWS Cognito user pool is the best fit.
We currently have Azure Active Directory with several thousand users in Active Directory. What does IdentityServer4 provide that I cannot get with connecting my .NET and/or Java apps to AAD alone? Can AAD provide me with an auth token that can be used to access the front-end app as well as the back-end API?
The key benefit is control (you can model your clients and resources and taylor your UX as you see fit) and the ability to use it as a federation gateway. E.g. if you need to support multiple customers many of which may want integration to their own IDP.
So I want to have single sign in, in all the products using a auth server but that's not only for employees, keycloak should be used to that like auth0?
There are also some advantages to Keycloak:
Keycloak is also available with support if you buy JBoss EAP (see http://www.keycloak.org/support.html). This might be cheaper than the enterprise version of Auth0. If you want to use custom DB, you need enterprise version of Auth0 anyway.
Keycloak has features which are not available in Auth0:
Fine-grained permissions and role-based access control (RBAC) and attribute-based access control (ABAC) configurable via web admin console or custom code or you can write yuour own Java and JavaScript policies. This can be also implemented in Auth0 via user rules (custom JavaScript) or Authorization plugin(no code, less possibilities). In Keycloak you can do more without code (there are more types of security policies available out of the box e.g. based on role, groups, current time, an origin of the request) and there is a good support for custom developed access control modules. Here some more detailed research would be interesting to compare them.
Keycloak also offers a policy enforcer component - which you can connect to from your backend and verify whether the access token is sufficient to access a given resource. It works best with Java Web servers, or you can just deploy an extra Java Server with Keycloak adapter which will work as a gatekeeper and decide which request go through and which are blocked. All this happens based on the rules which you can configure via Keycloak web interface. I am not sure such policy enforcer is included in Auth0. On top of that, Keycloak can tell your client application which permissions you need when you want to access a given resource so you do not need to code this in your client. The workflow can be:
Client application wants to access resource R.
Client application asks Keycloak policy enforcer which permission it needs to access resource R.
Kecloak policy enforcer tells the client application which permission P it needs.
The client application requests an access token with permission P from Keycloak.
The client makes a request to the resource server with the access token containing permission P attached.
Policy enforcer which guards the resource server can ask Keycloak whether permission P is enough to access resource R.
When Keycloak approves, the resource can be accessed.
Thus, more can be centralized and configured in Keycloak. With this workflow, your client and resource server can outsource more security logic and code to Keycloak. In Auth0 you probably need to implement steps 2,3,6 on your own.
Both Auth0 and Keycloak should be able to achieve your goal - assuming you want only social (facebook, google etc), and /or username & password authentication?
Auth0 is the less risky option, keycloak is good for non-commercial & where you can afford production outages without a global 24x7 support team. Here a few other reasons why I'd recommend Auth0 - the documentation is world class, they have quickstart samples so you can get up and running in minutes, and easy access to more advanced options - passwordless, authentication, MFA, anomaly detection, x9's reliability, rate-limiting, an extensive management api, extensions for everything eg exporting logs to log aggregator, and so on. Anyhow, good luck with your project, and obviously what suits best may simply be down to your own project requirements.
Should add, if you are doing mobile, then Auth0 put a lot of effort into adding the necessary specialised security flows to target mobile (native / hybrid) apps. For instance, PKCE usage when using /authorize endpoint. Please bear that in mind, as not certain how keycloak has been implemented to handle this - alot of IDMs still do this incorrectly today.
I'm currently developing a API to commercialized in a B2B SAAS fashion.
The goal is to authenticate the worker of the company. We have an SDK that should be able to do that. There is the possibility to force each user to set credentials specific for our service, but that will hurt integration with companies applications.
The idea would be to have some kind of authentication (client independent) that make it easier to authenticate users.
The question is: There is a easy way to create an automatic process that does not depend on the client type of authentication methods, for this type of task?
Thanks in advance.
Have you taken a look at Azure AD? It specifically supports multi-tenant scenarios.
Tenants can use Azure AD Connect to sync their on-premise directory to the cloud. Clients can use ADAL to acquire a token which your service trusts. The issued token contains a tenant-id claim indicating via which tenant the user logged in.
Just to add to MvdD answer, in Azure AD support three ways to sign in:
Federated Single Sign-On enables applications to redirect to Azure AD
for user authentication instead of prompting for its own password.
This is supported for applications that support protocols such as SAML
2.0, WS-Federation, or OpenID Connect, and is the richest mode of single sign-on.
Password-based Single Sign-On enables secure application password
storage and replay using a web browser extension or mobile app. This
leverages the existing sign-in process provided by the application,
but enables an administrator to manage the passwords and does not
require the user to know the password.
Existing Single Sign-On enables Azure AD to leverage any existing
single sign-on that has been set up for the application, but enables
these applications to be linked to the Office 365 or Azure AD access
panel portals, and also enables additional reporting in Azure AD when
the applications are launched there.