I'm using Azure ACS for authentication to my Web API project and it's working great with IP's such as Google and Live. I have a requirement to allow third party (partners) to develop against my API but I'm not exactly sure how to authenticate them. I'm thinking I may have to write a custom STS and manage usernames and passwords for each partner. In this scenario the partner would request an access token from my custom STS via a username/password and than use that token to access my API. Also I see Azure ACS has Service Identities, I'm wondering if I can use them in order to authenticate to my API?
Yes, you can.
Create Service Identity with authentication by x509 certificate
Create Rule Groups with rules where mapping Service Identity Name to selected claim
In your application in Relying party applications check new Rule Group in Authentication Settings.
Related
I have to design an IAM solution for a NodeJS microservice using Auth0. Objective is to allow third party mobile application users to access this microservice.
I understand OAuth and OpenID connect solution and one simple solution is third party application accesses APIs as a client using client credentials workflow.
Solution I have to design is allowing users to login and authenticate using their Enterprise IdP connected to our Auth0 Server. So that we can implement authorization and access control at user level.
At the same time customer application needs to be kept agnostic of Auth0 service.
What I mean by it is client should not be required to add any logic in their application for accommodating our Auth0 domain like we have in first party React application. user once logged in to customer application should get access to our API also by using SSO capability. I have read some documents about configuring customer IdP with our Auth0 server acting as a SAML SP. Still I could not understand hows of it and will Auth0 create an OAuth access token in this scenario.
I realise this requires an app to intermediate between customer's mobile app and our API service. Still, I am not able to understand data flow and communication between various components.
Also, I am not sure it is a common situation or requirement? If it is is there any technical term for it? This not seem like a standard B2B scenario.
have to design an IAM solution .. , I am not able to understand data flow and communication between various components ..
Before answering, the answer will points the asked specific questions, may not fit al your needs. SO is not really intended for writing tutorials or searching the documentation. Implementing an IdP (effecively a security module), one needs to do his homework and learn the details.
Maybe using an ready / out of box solution could be interesting. Using an open source IAM such as KeyCloak, WSO2IS could be a quick start. Or cloud services such as AWS Cognito, IBM AppId, Azure AD, .. could be a feasible solution too
a client using client credentials workflow .. access toked received by our API should be for user logged in
The client credentials grant is intended to authenticate only applications. That's it.
To authenticate users, other grant type is needed. For the user authentication the most common option is the authorization code or the implicit grant. The implicit grant is has its weaknesses and is being replaced by the code grant with PKCE (just search it).
End requirement is users of 3rd-party application not required to login again while 3rd-party application fetches data from our API .. Configuring their IdP (most probably Active directory) and our Auth0 servers for the same is all I need to understand
I see most common two options in use:
1. federated SSO authentication
This is the most commonly used option. The external (3rd party) IdP is configured as a "trusted" federated IdP. You often see the scenario when you have a service provider allowing to login with other IdP, often social networks (FB, Google, ...)
The login flow is as follows:
The client authorizes with the provider's (yours) IdP (let's call it IdP1).
IdP1 now acts as as Service Provider with IdP2 (IdP of the partner) and asks for the authorization (redirects the user to the IdP2).
User is authenticated and authorized with IdP2. If the user is already authenticated, the IdP2 doesn't need to ask the user's credentials again, this is how SSO works on this level
IdP2 returns to IdP1 (acting as a service provider).
IdP1 reads the user information (using the id_token, userinfo service - assuming using the OAuth2/OIDC protocol all the time there are other protocols too) and builds its own the user-level token. It may or may not create a local user (it is called user provisioning).
IdP1 returns to the client and the client can request a user-level token.
Then the client can call the API services with the token trusted by the API provider.
2. Assertion Framework for OAuth Authorization Grants
This option is built on top of the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, it is an optional extension of the OAuth2 protocol. I call this a token swap service
Basically the token service could validate the access or ID token of a trusted (partner) IdP and issue its own token based on the provided user information.
As you see there are a lot of information and to build a secure solution you ned to make sure that all steps are properly secured (signature, expiration, issuer, validity, audience, subject domain, .. are validated). Disclaimer - as my job we implement IAM/IDM solutions and a lot can get wrong if shortcuts are taken. So you may really consider using an out of box and proven solution.
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.
I am creating a WCF REST API to be consumed by a ASP.NET web application and mobile applications and an outlook add-in. The current infrastructure is hosted on premise but we plan to take it to the cloud soon.
The API needs to authenticate AD users via PingFedrate SSO. The current classic ASP application integrates PingFedrate and throws a challenge window to the user for authentication. I need to get the same via the API but stuck as to how to begin and where shall it lead.
Any pointers of suggestion from you experts?
This sounds like something you could use PingFederate's OAuth support for.
We (Ping Identity - my employer) have more information on how to authenticate using PingFederate SSO to get OAuth API Access Tokens (to secure your API and tie identity to it) on our Developer Portal.
Please see the follow links/articles:
https://www.pingidentity.com/content/developer/en/learn.html
https://www.pingidentity.com/content/developer/en/resources/oauth-2-0-developers-guide.html
https://www.pingidentity.com/content/developer/en/resources/openid-connect-developers-guide.html
I have hosted a web service on App engine cloud endpoint. The APIs are protected by Auth2.0 as google say but for google accounts.
What I want to achieve is allow these APIs to be accessed using 3rd party tokens. Lets say I have my on Authentication server also providing User Management. I want my google endpoint APIs to be access based on the 3rd party token I provide at the time of API call.
Is this possible?
If Yes, Where should I write the mechanism to verify the clients authenticity and hint of how its to be done.
Also is there any demo project available that provides user management and authentication server and returns a token that can be accepted by App Engine.
Yes
On your app engine project, create the authentication mechanism to validate clients.
As such, there is no single solution available for User management, Authentication Server and Token Issuance, but separate modules are easily available.
We are using WSO2 Identity server for our product. As for as our applications are concerned, we're authenticating the users with the IDS. We now want to integrate with third party product. And we suggested them also to use WSO2 IS for their identity service [auth/auth]
When I send a request to third party application, their application should authenticate our application request and accept the request. Can they add our identity provider as their trusted authentication provider, and that would help the user request getting authenticated against our identity source?
Is this possible? If so, please point me to sample where it is done!
Yes. It can be done in different ways. As an example, Your 3rd party application is a liferay, You can use WSO2IS as openid provider. Because liferay allows to login to it portal using openid. Else your 3rd party application supports for SAML2 sso, WSO2IS can be used as SAML2 SSO provider. If 3rd party app, is IIS hosted application, you can use Passive-STS.
Also, if 3rd party application does not support any common standard, there may be extensions that can be used to extent their authentication mechanism. If that case, you can write extension to 3rd party application, to call WSO2IS API. Because all APIs are web service APIs.
You can find more detail of integration
[1] OPENID : http://www.soasecurity.org/2010/08/sign-up-with-openid-providered-by.html
[2] SSO : http://tanyamadurapperuma.blogspot.com/2013/09/configure-wso2-identity-server-saml2.html