Can anyone please confirm what a tenant means from SCIM RFC https://www.rfc-editor.org/rfc/rfc7644.html#section-6?
If resources (i.e users/groups) synced from client (i.e, Azure AD or Okta) can also be accessible or in-accessible by other clients, then does it means multi-tenant scenario?
Think of a SaaS service provider like Dropbox - where the SaaS provider may host hundreds or thousands of separate environments, typically broken by customer/organizational boundaries. That is what multi-tenancy means in this context.
Related
The cloud solution I am working with requires a multi-tenant app registration to be created and used for service-to-service authentication in a SaaS like pattern. The security team expressed concerns that a multi-tenant identity could be assign resources by another tenant (or external entity) without the security team's visibility or control. Assuming the App Registration is only used to configure the solution and its not used in the organization for any other purpose and it's fully protected in Azure Key Vault and not shared with any external entity, is this a legitimate concern? Could there be a way, just because it's a multi-tenant App Registration for it to be discovered and used in a harmful fashion?
As long as you use key vault to store the client secrets properly malicious entities won't have access to the tenant. In fact, an even better mechanism will be to use a certificate in place of a secret.
I know Azure AD would probably be pretty good for crediting a enterprise-class application, i.e. something used inside a corp. However what about if I am creating a public facing internet application. I need typical identity components, sign-in, sign-out, etc. Let's just say 10,000 users. Would azure AD be good for this?
I think azure ad b2c will meet the demand.It provides business-to-customer identity as a service. Your customers use their preferred social, enterprise, or local account identities to get single sign-on access to your applications and APIs.You can customize the entire user experience with your brand.Azure AD B2C uses standards-based authentication protocols including OpenID Connect, OAuth 2.0, and SAML. It integrates with most modern applications and commercial off-the-shelf software etc.You can refer to this.
I have successfully configured qn Azure AD App Registration, allowing a client_credentials based OAuth 2.0 flow to work. This allows a third party application to access Microsoft Graph API. The app has "Calendar.Read" permission. Meaning the app can pretty much read any of the calendars (including CEO's).
I now have a conversation with security. What is out there in the Microsoft world, that I can use to lock down usage of API access via this Application Permission? Is there ability to do things like:
Restrict IP ranges the App can be accessed from?
Restrict users that can access the App? (However in Client_credentials, there is no user context)
Log traffic / activity happening via the App?
The only thing i can think of now is to say the Redirect URL configuration on the app means, no other application can get an access token using the Client_credentials, even if the application id & passkey get compromised
Any advice on further security controls that can be put in place?
Restricting access: You would need to do this in your application. The Client Credential flow doesn't allow for restricting what users as you point out. However there is nothing stopping you from adding user authentication to your application, possibly using a delegated graph auth flow to determine who they are.
IP Ranges: This is not possible currently.
Logging Traffic: This is not possible on the graph side currently, however you could/should log traffic on your applications side.
Redirect urls will not help you because they are not used int eh client credential flow.
In general application only auth (client credential flow) + a broad authorization scope is very powerful, but must be managed correctly. You don't inadvertently want to build a totally new users/permissions model over the top of the graph :)
There are very few options available currently available to offer these controls at token issuance (in Azure AD) or at API access (in Microsoft Graph). However, you can achieve similar results by carefully managing access to the app's credentials. Here are a couple steps you can take (not exhaustive):
App credentials: keep them secret, keep them safe
Use Key Vault. You can configure many of the restrictions you mention for access to data in Key Vault, including IP ranges and which users access. Key Vault also offers auditing of access to secrets. Don't forget to also be careful about which users have management access to the Key Vault (e.g. other users with access to the same Azure subscription).
Use certificates (public/private key pair), rather than client secrets (passwords), to authenticate the app. People tend to manage certificates much more carefully than they manage shared passwords, and developers are much less likely to hard-code the secret into scripts/code.
Be careful and deliberate about which users can manage the app's credentials
This is often overlooked. A user (or another app) who can access existing credentials, or add a new authorized credential to an app can act as the app and (mis)use all the permissions the app has been granted. This includes:
Users (and apps) in the "Company Administrator", "Application Administrator" and "Cloud Application Administrator" directory roles.
Users who are set as owners of the app registration (Application object) and enterprise app (ServicePrincipal object) for the app.
Users (or systems) who have access to the server or service the application resides on (which will have, or have access to, the credentials).
For all of these cases, ensure this is the smallest possible number of users, and they actually have a legitimate need. For users who do need access, wherever possible enforce just-in-time, time-limited access (not persistent access), such as with Azure AD Privileged Identity Management, for time-bound, just-in-time access for Azure AD directory roles and Azure resources.
I was just playing around with OpenAM and found that authentication can be done through SAML as well as cookie based approach of CDSSO. Now my concern is if I am working in domain like banking and healthcare how feasible it would be to go for CDSSO cookie based approach and is their any organization who is practicing cookie based approach in any such domain.
SAML is designed for connecting independent security "domains". The term "domain" in this instance has nothing to do with network domain names, but a rather more nebulous term, meaning a division between security systems. An example to explain a bit better: Company A uses OpenAM to protect its intranet websites, but they also use services from Salesforce. SAML is the obvious choice here - Salesforce isn't going to use a cookie from OpenAM... How could they? You could also use it to interconnect two different systems inside a company (and domain name), like OpenAM and Siteminder, since those two systems can't communicate directly via their cookies.
CDSSO is primarily designed for use inside an organization that could have multiple domains that they protect. They can have multiple policy servers in multiple domains, but all of those servers are managed by the same OpenAM instance, and they all share a common backend. Lots of organizations use OpenAM's (and OAM's, and Siteminder's) CDSSO capabilities. But they use it inside the systems within their control.
In addition, I can't think of a single service provider that would want you to place one of your OpenAM policy servers inside their network. You wouldn't want them touching your server, and they wouldn't (if they are right in the head) trust you to not be dropping a trojan in their network.
TL;DR:
SAML - outside of an administrative domain
CDSSO - inside an administrative domain
SAML is the standards based way of achieving SSO for, Agents is the proprietary way.
SAML does not offer any authorization (which user is allowed access to a given resource) out-of-the box ... that's the backdraw.
I've been investigating some cloud vendors and the ability to implement single sign-on with them, especially when it comes to AD (Active Directory) integration.
So far I've learned that with Azure this is possible through ADFS and the AppFabric Access Control offer.
In AWS, since it is possible to create a VPN and see EC2 instances as a natural extension of a private datacenter, I believe implementing SSO would be rather simple (not sure if I'm right on this one... Please correct me if I'm wrong).
With App Engine though, even though there is some documentation on AD synchronization (not full integration) for Google Apps, I'm struggling to find out whether AD integration would be possible... Is there any strategy for that?
Any bit of information on cloud apps and AD integration will be appreciated!
App engine apps can only call out to other services using HTTP or HTTPS, so you could not directly query an AD server. Of course, I'm sure you could build a simple HTTP/LDAP bridge if one does not already exist.
UPDATE: oops, I forgot about SDC,or Secure Data Connector. It is not exactly a HTTP/LDAP bridge, but can provide a bridge between your intranet and your Google App Engine app.
You typicially don't need communication between the application (in this case running in GAE) and AD.
You would, instead, get a security token from and STS (ADFS) and then send the token to the app that is would be configured to accept and trust those tokens.
I'm not familiar w/ GAE but assuming it accepts SAML tokens and understands WS-Federation, you can achieve SSO without ever exposing AD or synchronizing any information between AD and GAE (using ADFS for example)
This is a classic identity federation scenario.