I am trying to understand which authentication suits good for Azure Function app because I have to expose function app end point to external team.
I have enable Azure AD authentication and planning to share App registration client_id and client_secret (endpoint oauth2/v2.0/token) where they will generate bearer token to Authenticate and consume my endpoint.
I was wondering if there is any other best approach of authentication than Azure-AD because I am exposing to external team.
Please assist, Thank you.
the most secure option is to request access tokens trough the Azuthorization Grant Flow with PKCE. No secret is required, however if you need to use one, we recommend using certificate credentials which are asymmetric thus the exposure of the secret is more and better controlled.
You can also, configure token and enforce additional security measures trough Conditional Access policies. With them you can configure session lifetimes, require MFA for selected or all external users that access your application, that they authenticate from a compliant device, well known IP range or location, and more.
Also, and at the PAAS level, you can Set up Azure App Service access restrictions.
Related
I have created Azure function app python. We have source system Guidewire which calls this Azure function app. We are planning to add security level to function app so that any system connecting to function app need to authenticate and authorize. Please let me know how to enable this and how to perform authentication/authorization function app(python).
Thanks
Azure Functions lets you access your function endpoints in different authorization scopes like System level, admin level, user level and anonymous level.
While function keys can help prevent unauthorized access, the only way to completely secure your function endpoints is to use affirmative authentication for all clients who visit your functions. You can then make authorization decisions based on identity.
By providing out-of-the-box authentication with federated identity providers, the built-in authentication functionality for App Service and Azure Functions can save you time and effort, allowing you to focus on the rest of your application.
When you enable authentication and authorization with one of these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider. You can provide your users with any number of these sign-in options.
Azure Functions uses Azure Active Directory (Azure AD) as the default identity and access management service.
Please refer the what are the built-in authentications provided and customization details, authorization scope of azure functions and azure function security system in base line for detailed information.
I am using AWS Cognito for authentication in my application. Cognito provides fully client-side authentication. But, we need to store credentials in .env file which is accessible from the browser.
Is it secure to use AWS Cognito for authentication, if I am building an enterprise application and security is important for me?
For AWS cognito the authentication happens at server side. Not on the client side. At the client side we are creating the opportunity for the user to log via his credentials, then the credentials will be sent to AWS Cognito for authentication. Which results in a accept or reject.
Cognito itself is a service that you can build a secure identity foundation on - but not in the way you're proposing it.
Storing static credentials to 3rd party APIs in something that can be easily accessed by (un)authenticated users is a terrible security practice.
The security of Cognito is not your biggest problem, my advice would be to first find a better solution for your static credentials. Sometimes static credentials like API keys can't be avoided, but you should never expose them to your end users. Store them in something like the AWS Secrets Manager or the Systems Manager Parameter Store and retrieve them when you need them. Only store them in memory if possible and never send them to your clients.
I'm working in microservices environment, where each service authenticates using OpenID Connect to an authentication service (local IdP), based on Users I keep locally on my Database.
Now, I want these services to be able to authenticate using Azure, Google, etc.
Can (and should) I modify my authentication service to allow redirection to another IdP, and replace or chain the token to my proprietary token for my services?
Is there a simpler way?
How can I allow users to login both using name / password OR external IdP?
I'm doing some research on the topic by myself as well and from what I've found until now, it seems that there is a urn:ietf:params:oauth:grant-type:token-exchange grant type that should allow exchanging external idp token to an internal one as described in some spec.
It should be supported as part of the openid connect /token endpoint so as long as the local idp supports it, I guess that this should be the best practice to achieve what you are looking for.
I'm currently looking into mitreid-connect idp implementation as local idp and some of my requirements is to also allow SSO with third parties while being able to issue a local token from the external user identity.
Will update as it goes...
If you manage all the SP (your microservices) it's definitely easier to implement it on your common IDP.
But if the SP are external ones (like existing services you just installed) and they already implements the public IDP you want to use, it was be a bit harder to pass through your current IDP without problem.
I'm guessing you are in the first case (you made all your SP) so I will elaborate it:
When your current IDP will authenticate user on others public IDP, it will get some information (email, name, etc.) and you can normalize those in your answer, to be sure your SP are completely agnostic of which original IDP was used. It will be better for you if the future to debug this setup. And of course to add a new public IDP...
But if you need to use some specific call to original IDP, (let says Youtube API for example) you could have a agnostic API on your common IDP which will forward to the appropriate proprietary API of original IDP, or deny the request if the IDP does not have a video system.
Or you could give original token to your SP, in a custom field or scope of your oidc token, so for example an SP dedicated to video could directly call Youtube API with the google user token.
I recently did a similar setup for my company. I would like to share the overall structure to give an idea about our solution. Hope it helps:
Our authentication server is an node express server with following properties:
Hosts static login screens to allow authentication against local database via email + password, as well as provides links to authenticate with external OAuth2 providers.
Both local and external authentication requests are forwarded to Passport.js Authentication strategies
After successful login, both local and external Passport.js strategies respond to a callback. Upon this response, a session object is created via express-session and a cookie is sent.
At this point, cookies can be used to exchange JWT's, so that authentication against stateless API's can be possible with Bearer Access Tokens.
I'm trying to find a suitable way to implement the identification approach in microservices. I would be happy if you help me to cover my questions:
- How can we register services and external applications as an identified service?
- How can we authenticate and authorize them when they want to connect together?
If I understand it correctly, you are looking for the ways to authenticate the clients that try to access your microservice, if it is so I think you can use OAuth2 Client Credentials flow. Deploy an OAuth2 authorization(AZ) server. OAuth2 AZ server registers your clients and provides them clientid and client secret.
When the client wants to access your microservice it first authenticates itself to OAuth2 AZ server with clientid and secret, and gets an access token. This access token is presented to your microservice which can then determine the access control to provide the response accordingly.
https://www.rfc-editor.org/rfc/rfc6749#section-4.4
In our organisation we use the Google Kubernetes Engine (GKE) to implement a micro-service architecture. As we are also G-Suite users, everyone in the organisation is guaranteed to have a Google account. In consequence we would like to use those accounts to manage authentication and authorization of micro services.
We have prototyped login using the angularfire2 client to authenticate against the Google Identity Platform. We also have Google Cloud Endpoints configured to control access to relevant services.
The piece we are missing is how to get from the identity in Google to an access token we can use on our services -- the access token coming back using the Firebase API has no claims in it, and the documentation on custom claims seems to make it quite clear that these go into the identity token.
My expectation would be to have JWTs with the appropriate audience (our backend), containing a sufficient set of claims to implement role based access control within the services. Ideally the infrastructure could validate a claim already -- some of our services are small enough to require only one role, which could be enforced outside the service. Or we could annotate our endpoints (Protobuf) with the required claims.
In the GCP environment, what is the standard process of creating access tokens to be used for accessing GKE services? Is there anything that supports this?
The piece we are missing is how to get from the identity in Google to
an access token we can use on our services -- the access token coming
back using the Firebase API has no claims in it, and the documentation
on custom claims seems to make it quite clear that these go into the
identity token.
Google OAuth Access Tokens do not have an identity in the sense that you want to use it. Identity is stored in the Identity Token. Add the scope "email" when authenticating the user. Google will return an ID Token. For some frameworks, you can request custom claims for the Identity Token.
In the GCP environment, what is the standard process of creating
access tokens to be used for accessing GKE services? Is there anything
that supports this?
There are two types of access excluding methods such as API keys. User Accounts and Service Accounts. Service-to-service typically uses service account Access Tokens (RBAC) or service account Identity Tokens (IBAC). In your case, you want to use Identity Platform which means User Accounts.
If I was designing this system, I would use User Accounts to authenticate with the system - Firebase is great for this purpose. I would look up what roles this identity supports/allows from my database (Firestore) and create a service account Access Token with the required scopes for GCP services. I would then use this Access Token for GCP service-to-service authorization. If I also required custom roles for my own services, I would create a custom Identity Token with my custom roles and include that as a custom HTTP header and include the Google Access Token in the standard HTTP "authorization: bearer" header. I would use the service account private key to sign my custom Identity Token or use a GCP IAM API to sign for me so that the other end can verify with the service account's public key. This method prevents data leakage at the client, no private keys are distributed, scopes/roles are not disclosed, etc.
I would suggest you follow this doc of authentication between services by using service account files.