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.
Related
For my current ASP.NET Core MVC application I authenticate directly with a web app registered in Azure AD Portal. This provides me with an access token so on the backend of my web application I can use MS Graph with my users specific account (ie add files to their onedrive , email, etc). However, my organization also has Okta which a lot of applications authenticate against. So I was trying to determine to authenticate through Okta (which has a much cleaner sign in process IMO) as well as authenticate against Azure AD and get an access token. Through my research I found something in my web application registration in Azure AD called Workload Identity Federation. This led me to this useful video
https://www.youtube.com/watch?v=wZ0gCJYMUKI
and also microsofts info site:
https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation
This seems to answer what I want which is to use Okta but allow me to still use MS Graph for my users since it will authenticate against Azure AD (correct me if I am wrong and this is for something else). My issue is none of these resources really go into depth regarding how the access token is passed to my application so I can use MS Graph. My research this is called client credential flow since my application only has delegated permissions so it requires the users to log in and it basically allows my web app to act on their behalf when using MS Graph. So I am trying to understand and fill this void of information regarding how client credential flow fits into Workload Identity Federation and is this the solution to my problem.
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 was learning about IAP in GCP, which is used for authentication and authorization to GCP hosted apps.
Thoughts
Even before IAP was introduced in GCP, users could be authenticated and authorized using login credentials and google IAM policies.
Okay, IAP replaces VPN, users can work from untrusted networks.
Query
Please correct me if i am thinking wrong.
But if my app./resource is hosted in GCP, than it is accessible publicly with proper authentication and authorization, there is obviously no need of VPN. In this scenario, what is the significance of IAP.
What is the new thing in IAP, as IAP also does the same thing for authentication and authorization?
You wouldn't technically need IAP if you've already got an app which is secured with proper authentication and authorization, though it still may be desirable. One reason is that IAP gives you the ability to configure individual access outside of your application, rather than needing to control ACLs internally in your app's code. The App Engine IAP quickstart has a good overview of how IAP config works for securing an app.
You can think of IAP as filling the role of a VPN while also giving you the flexibility of OAuth. It is mainly targeted towards perimeter security which is traditionally accomplished by using firewalls and VPNs to secure privileged network resources like intranets which are hosted on premises. IAP allows you to set up a cloud-hosted intranet in much the same way as you'd do on-premises, with access control handled at the perimeter by IAP. This is explained very well in the Google research paper "BeyondCorp - A New Approach to Enterprise Security".
Active Directory Federation Service and IdentityServer3 are both STSes that allows Single sign-on to software systems.
I read that IdentityServer3 can use smaller (than SAML 2.0 in AD FS) JWT tokens and can be highly customizable like using different user repository.
But if I have all users in Active Directory and I can accept this bigger tokens and provide resources using AD groups will I have any benefits using IdentityServer?
In my system architecture I want to have WebAPIs connected using ESB. I will have different types of apps like mobile, Angular, desktop. I would like to use solution that will be more reliable than flexible.
Web API normally implies OAuth. ADFS 3.0 has limited support for this. ADFS 4.0 has the full stack.
ADFS 4.0 wrt. web API is functionally the same as idsrv.
Also ADFS in some cases does support JWT.
I am looking at a scenario wherein we would like to provision (i.e. create) users programmatically into AD from our app. I was wondering if AD offers any kind of SOAP based APIs that can be used for this purpose.
Anyone have experience / information regarding such a scenario?
ADFS doesn't have any users. Authentication (and "users") are always in Active Directory. There are many APIs to interact with AD. (e.g. Directory Services)
I'm not aware of a SOAP based API, but you could build one wrapping the API described above. Also, I would look into whether this is really necessary. If the provisioning engine is meant to be run in the same domain (e.g. on-premises) then you would not need SOAP.