Just wanted to understand if CF provides any support for SSO applications? If yes then how?
One of the use cases supported by the UAA is SSO. From the CF.org blog:
Because it is centralized, the UAA can provide a Single Sign On (SSO) service for applications in the Cloud Foundry platform. The cloudfoundry.com platform has several UI components and where they need to be secure they delegate to the UAA for authentication. Examples are the support site and the Micro Cloud Foundry site. (There are no other components in the core Cloud Foundry open source platform that have a UI, so it’s not really necessary to have an SSO feature until you grow the platform beyond the core use cases.)
The UI components that need SSO use the /userinfo endpoint in the UAA, which is just a regular OAuth2 protected resource (an example of the UAA acting as a Resource Server).
Related
I am trying to create a web application. This app is a B2B PAS model.
One of the features of the app is, an organization using GSuite, can onboard our system and then all its users can log in to our software using their org's google ids. However, in the application, one user can assign task to another user in org. So our application should be able to list all users of the org too.
How can both these features be achieved?
I have tried the SAML approach, by creating a custom app from Gsuite admin console. However, can SAML be extended to also list users from the organizations which the SAML app belongs to? (Basically trying to use the Google Cloud Directory API)
What other alternative approaches should I look for if pure SAML doesn't work out?
P.S tech stack I'm using is Nest JS for backend and Angular for frontend
If I am understanding properly you are looking for the way to populate all users/ID from organization to your SAML App. Single sign-on (SSO) allows users to sign in to enterprise cloud applications using their managed Google account credentials, more details here in set up your own custom SAML application. It is also possible to Set up SSO using 3rd party IdPs.
However, Google supports several industry standard protocols like OAuth 2.0, OpenID Connect 1.0 and SAML 2.0 for handling authentication, authorization, and single sign-on. You can take a look at authenticating corporate users in a hybrid environment for more details.
What could be an alternative to custom federation broker on aws in azure and google. In AWS I am able to create a url that permits federated user to login and access resources like this -
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-custom-url.html
How we could create the same in azure and google?
This answer covers Google Cloud Platform.
The basic foundational identity for Google Cloud (GCP) is Google Accounts. This means that the users are required to have a Google Identity before you can setup federation / SSO. GCP IAM permissions are assigned to email addresses (User, Service Account, G-Suite Group, etc.).
Where AWS requires a custom URL for SSO, Google implements OAuth. This means once authenticated, users can just use Google services without needing special URL entry points. In this respect Google's SSO is smoother for end users.
GCP supports SAML 2.0 SSO. Google acts as the service provider and the third party (AD, Okta, etc.) act as the Identity Provider. This requires you to setup Google Cloud Identity.
I went thru this process and just like AWS, it can be complicated. One item to think about. Do you plan to use GCP as your primary cloud plaform or one of the other vendors. The reason is that if GCP is your primary platform, then everything will be a lot easier if you also implement G Suite first. However, if you are a Microsoft shop where you want Active Directory to be your Identity Provider, then SAML is the implementation path. Just be prepared that you will need to setup directory synchronization (connectors). Google has a good connector for Azure Active Directory. This video provides a good introduction to extending Active Directory to GCP IAM.
This article will take you step by step thru setting up the correct Google services, SAML SSO, setting up Identity Providers, etc.
Using your existing identity management system with Google Cloud Platform
Additional Reading:
Google Cloud Identity
Setup SSO
Set up your own custom SAML application
I'm building an app and the idea is to go serverless.
I'm looking mainly at AWS and GCP (Google Cloud Platform), and as AWS costs are a bit obscure (at least for me), and there is no way to ensure not being billed, I'm going with GCP.
For the "server" part of the app, I would like to build an API on GCP as I could do with AWS API Gateway, but I couldn't find any matching product for that.
The closer one was Google Cloud Endpoint, but it seems to have a very different concept from AWS API Gateway. I've watched some videos about it (for example https://www.youtube.com/watch?v=bR9hEyZ9774), but still can't get the idea behind it or if it fits my needs.
Could someone please help clarify which GCP product would be suitable for creating an API and how it compares to AWS API Gateway?
Some link with info/example on how to do it would be really appreciated.
Google Product Manager here.
We don't have an exact analog for AWS API Gateway.
You're right about Cloud Endpoints. It's a bit of a different architecture than AWS uses -- it's a sidecar proxy that gets deployed with the backend. That's different than API Gateway, which is a fully managed proxy deployed in front of your backends.
If you are deploying in App Engine Flexible environments: good news! The Endpoints Proxy can be deployed as part of your deployment. It can do things similar to AWS API Gateway (API key validation, JWT validation, rate limiting).
We are working on some plans to allow for the proxy to be used in other places (Cloud Functions and the newer App Engine Standard runtimes).
And, finally: on our older App Engine Java and Python runtimes, we have API Frameworks that provide the same functionality. Those frameworks do the same thing as the proxy, but get expressed as code annotations and built into your app. We're moving away from the framework model in favor of the proxy model.
An example of springboot project with google cloud app engine can be found here-https://github.com/ashishkeshu/googlecloud-springboot
I have developed a set of Jersey-based REST APIs and deployed them to a Tomcat application server running on Elastic Beanstalk. Our application architecture requires that these REST APIs be accessed from an AngularJS web front end. The web front-end requires user authentication and we want all the accesses to these APIs to be restricted to users who are authenticated. This is a pretty common application architecture pattern.
Now mapping this architectural pattern to AWS services, we configure a Cognito user pool to authenticate users. We map this user pool to an identity pool, to which we attach a policy that allows for access to Beanstalk applications. From here, I don't know what to do next in order to configure secure access to REST APIs. A number of areas in this technical architecture are still not clear to me.
1) How to secure REST APIs on the server (i.e. AWS) side
Because we are using Tomcat container to host Jersey application, the "standard" JEE approach is to declare security constraint in web.xml, as demonstrated in the example below:
<security-constraint>
<web-resource-collection>
<url-pattern>/rest/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
I am wondering if this role-name "admin" will be ingested by Elastic beanstalk? So if I defined a role "admin" in IAM, and specify the above stanza in web.xml, will Tomcat app server at runtime perform the check? In my application, if I use standard SecurityContext.isUserInRole("admin"), SecurityContext.getUserPrincipal() etc, what kind of values will be returned?
2) web front end service invocation
because we are using AngularJS, the standard approach is to use the built-in $http service to invoke remote REST APIs. Suppose a user logs in through Cognito successfully, and obtains a JWT access token, how should we pass it to the http call to the REST API? Will AWS Javascript SDK automatically add proper HTTP headers to the $http service call or we need to handle this explicitly in our code?
I have researched quite a bit in the Elastic Beanstalk documentation, in particular the section of "integration with IAM service". However, the documentation does not seem to cover my questions above.
I would like to understand:
1) architecturally, how my questions above could be resolved in AWS Beanstalk. I am sure it can be done as it is a common architectural pattern. I just couldn't find the right answer in the documentation.
2) is there a pointer to some sample code? I went through some Java web app samples and built one by myself. However, these samples do not cover my requirements above.
Appreciate if any friend could enlighten me on this topic.
zx999
I am working on a web application implementing online shopping functionality. I am using Struts2 + Spring + Hibernate. I am using Spring security to implement authorization and authentication.
Now my client wants to develop an iOS/Android App for the same where users of my web application can login and use some of the functionality using the app.
Mobile App will access the REST based web services on JSON which will be implemented using Jersey. Here are my questions:
Users are going to have a role from three of the roles. Depending on the role they should be able to access the specific resources. I am thinking about using Spring Security 2.0 with Jersey and authenticate the users using OAuth 2.0. Is OAuth 2.0 right applicable choice?
Also, Jersey doesn't support oAuth 2.0 on server side. Still I guess I should be able to use any other OAuth provider to secure Jersey services right?
If oAuth is not the right choice then what I can use to provide role based authentication and authorization for Mobile App users to my REST web services.
Don't forget you can use simple HTTP BASIC auth (with SSL, of course).
For comparsions of OAuth versions, see this.
After having to deal with the same problem I did some research and currently I can see 3 solutions.
Pivotal actually have a piece of software which they use for their cloudfoundry services, called UAA (User Account and Authentication) Server. You can deploy this to your own server, and it's role is basically to provide OAuth2 access tokens. You will need to create your own Resource Server which will serve different resources if the correct OAuth token is provided in the request. (they have a couple of sample apps in the UAA repo which you can use) https://github.com/cloudfoundry/uaa
Google actually provide services like that. If you host your backend on appengine you can use cloud endpoints to expose your API and they take care of Authentication and Authorization.
https://cloud.google.com/appengine/docs/java/endpoints/
You can create your own architecture. Basic approach would be to have an Authorization server (to generate tokens), an Resource Server (to serve your API) and some sort of storage for users and tokens.
Hope that helps a bit, I'm personally going to go with the UAA to try it out.