Many talk about how SCIM allows you to transfer identities between systems or service providers.
Are there any built in hooks or API-endpoints for allowing SCIM servers to talk directly to
other SCIM services? Or are there always a client in between orchestrating the exchange?
Imagine I wanted to transfer my Identities at Google to SalesForce, how would that practically be done and implemented?
I know SCIM provides a REST-API, but somehow someone needs to orchestrate the transfer.
(CSP->CSP) is defined in the point 2.3 of this doc https://datatracker.ietf.org/doc/html/draft-ietf-scim-use-cases-01
I can think of many scenarios on how Google and Salesforce would interact, but that decision ultimately belongs to them.
Related
I am currently learning SCIM and one thing that I have come across is the SCIM endpoints need to be on the public DNS so IdPs can call out to them. I have used ngrok to expose my localhost over the internet for testing purposes but I was curious if there is any way I can accomplish this by not exposing my SCIM endpoints on the public DNS. I believe with Azure AD this is possible via the Azure AD Provisioning agent but I was wondering if there was an alternative like the Azure Provisioning agent or anything else for other IdPs such as Okta or PingOne.
Thank you
The SCIM protocol, at RFC-7644, doesn't specify anything about the implementation details of a provisioning agent. The protocol dictates the language that both the IdP and the target domain app will have to share. It doesn't even dictate the authentication layer.
But your point is valid: what if your SCIM REST API has to be network-gated?
A provisioning agent is purely an implementation-specific component that different identity providers opt to provide their admins as a means to allow SCIM provisioning in network-gated environments (e.g., the Azure AD Provisioning Agent and the Okta Provisioning Agent). If your SCIM REST API is gated behind network constraints that disallow the IdP's direct network access, you'll need an agent, but it's important to stress that the agent itself is not part of the SCIM protocol.
In other words, a provisioning agent is a courtesy given to you by your identity provider and not the SCIM 2.0 protocol.
Whether you seek to set up your development or production environment, how your IdP interacts with that environment's SCIM REST API is a decision to be made - agent or no agent. As for your local development environment, it's entirely up to you to decide whether you keep using a reverse tunnel like ngrok or decide to install your IdP's agent on your development stations.
A side-note on event-driven architecture:
I recently wrote a blog post on SCIM 2.0 provisioning on a high level. The idea is simple: instead of "scraping" the state of the identity provider's user pool, you're switching to an event-driven mindset, wherein the IdP informs your SCIM tenant (i.e., your SCIM REST API) of movements in your user pool. Switching to working with an agent kind of augments the idea behind that event-based architecture of SCIM 2.0, but it does work around the network constraint that a lot of organizations have.
In my webapp architecture i have an api gateway which proxies requests to my microservices, also there is a a common microservice which other microservices can query via rest api. All of these run on node servers.
i want the microservices to only be approachable from the api gateway, besides the common server which can also be approachable from the other microservices. what is the best network architecture to make this happen and do i need to handle authentication between the servers in some way?
Security needs to be handled at multiple layers and as such its a really broad topic. I will however share some pointers which you can explore further.
First thing first any security comes at a cost. And it's a trade off that you need to do.
If you can ensure that services are available only to the other services and API gateway, then you can delegate application layer security to API gateway and strip the security headers at API gateway itself and continue to have free communication between services. It is like creating restricted zone with ip restrictions (or other means on from where can service be accessed), and api gateway or reverse proxy handling all the external traffic. This will allow you to concentrate on few services as far as security is concerned. Point that you should note here is that you will be losing on authorization part as well but you can retain it if you want to.
If you are using AWS you need to look into security groups and VPN etc to set up a secure layer.
A part of security is also to ensure the service is accessible all the time and is not susceptible to DDOS. API gateways do have a means of safeguarding against such threats.
For the ‘API gateway’ front-end authentication you could use OATH2 and for the back-end part you can use OpenID connect which will allow you to use a key value that is relevant to the user, like for example a uuid and use this to set access control at the Microservice level, behind the API Gateway.
You can find in the next link further information about OpenID connect authentication.
I have my Rest API's configured in API Gateway. I want to implement OAuth on top of it so that the access to the url's are authenticated. I know that Lambda functions will be required here. Following are my questions:
1. Any good third party oauth providers that I can link with my project?
Scaling needs will be pretty high, possibly around 1M/second. Will these providers be scalable enough?
I would want to be doing everything programmatically. Like mostly these providers will require registration in order to acquire client id's and secrets. I want that also to happen programmatically as the no of users signing up will be dynamic.
i find Authlete good and also provide a guide for Amazon API Gateway
Yes, they can scale pretty well (check the pricing section) if you are willing to pay enough
We're trying to figure out a best practice for IPC authentication and authorization. I'll explain.
We have a micro-services based architecture SaaS with a dedicated service for authentication. This service is responsible for doing the authentication and managing auth tokens (JWTs).
Everything works perfectly good with users that login and start to consume resources from the different services.
The question now is how to authentication and authorize requests which being initiated by other services (without the context of a specific user)?
Should we generate a dedicated user per service and treat it like
any other user in the system (with appropriate permissions)?
Should
we have a "hard coded"/dynamic token deployed among the services?
Any other ideas?
Our biggest concern is such tokens/passwords will be compromised at some point since requests from one service to another is treated with high level of permissions.
Cheers,
I'm not a microservices expert, just started to get my feet wet in the microservices world. From what I've read until now, this could be handled in many ways, one of which as you mentioned is hard coding api-keys so that services recognise one another. But I never liked this idea personally - also using a user per service like you mentioned. A solution I really liked is using Oauth2 for handling these scenarios - an interesting implementation I found is Gluu Server and I think client credentials grant type is what you're looking for - refer https://gluu.org/docs/integrate/oauth2grants/.
Have fun :)
Normally, API Gateway is integral part of any MS system.
All the services encapsulated and should be not accessible without API Gateway.
Such encapsulation allows direct communication between the services, without providing the requester payload, which should be required if the request comes straight from API Gateway.
In that case the request threated as something different, and follows different logic/middleware pipeline. No additional special users needed.
My company is planning to host some applications on public cloud. For identity management in cloud, my understanding is that we have 3 options
Federation
Provisioning
Identity as a service
My understanding for federation is that any access to cloud based services, can be intercepted and pointed to identity provider within the organization, which will then perform authentication and authorization, provide a token and the application can inspect token and allow/disallow access
For provisioning, instead of identity provider being located within organization, it can be located in cloud and it can refer to identity stores in cloud, which are provisioned in batch or real time by standards such as SPML or SCIM
Is the above understanding correct?
An app being deployed to the cloud has little to do with identity federation or identity as a service. You could very well use Forms authentication on a cloud service.
The question is whether you want to make your app responsible for authenticating users or not. If you choose not to (which is likely a good thing), then you need to rely on a mechanism to outsource identity. The techniques to do this are referred to as "claims based identity", "identity federation", among others, and involve a number of protocols (e.g. SAML, SAML-P, WS-Federation, OAuth). These depend on the systems you want to use for authenticating users:
SAML/WS-Fed are typically used for enterprises (using AD for example)
OAuth is mostly used by consumer oriented systems (e.g. Facebook, etc).
So, depending on where your users are you might need to implement one or the other (or both).
Identity As a Service, means you use an external service provider to handle authentication with these providers for you. It is not a requirement and you could build this capability on your own.
Without details of your infrastructure and your app it is difficult to provide any guidance: ASP.NET? Java? nodejs?Azure? AWS? Heroku? Where are your users?