Can someone help me with my understanding?
So i understand how one can use ADFS and SAML to provide SSO access to the Console via IAM. However im not as clear how this can be done at the application level
So take MS Dynamics as an example. It will be on an EC2 instance which is on a domain controller hosted in the VPC (for mgt etc). However the users themselves will be in an on-prem AD server and we'd want to authenticate users accessing the dynamics web front end with that on-prem AD server. Is this as simple as setting up ADFS between the two sites and configuring the app itself to use ADFS / SAML for claims based authentication?
For application level support, it depends on the ability of the app to support claims based/SAML authentication. CRM supports ADFS configuration. You have one of 2 choices
You can hook it up directly to your on-premises ADFS if it is really about just providing access to your corporate employees. If it requires partner access that ADFS can still federate to other ADFS/IDP organizations.
You can set one up in AWS next to or on the DC that it has and treat it as a Federation Provider and then set up trust to the corporate ADFS where the users live.
I'd recommend #1 as it is simpler. Go with #2 only if you are operating this as a different company or you are building multiple server apps in this AWS site that require local ADFS for things like server to server communication.
Thanks
//Sam
Related
I have an ASP.net MVC Web application with on-premises Active Directory authentication, which I want to move to AWS PaaS service. My SQL database for the ASP.Net MVC web application will remain on-premises.
I did some research and found that AWS ECS is a good feature for containerization. But I am not looking for IaaS approach.
I am mainly looking for PaaS approach to migrate my on-premises application.
For the AWS Elastic Beanstalk Website, I am not finding an option to enable on-premises Active Directory Authentication. Is it possible?
Also can I connect to on-premises SQL server from AWS Elastic Beanstalk website using Windows Authentication/AD Authentication?
Yes. It is possible. I am using it.
It took lots of research and trial and error. As our AWS cloud VPC is in different domain than our on-prem AD domain and our users are in on-prem AD domain.
This is my setup.
We have setup managed AD in AWS domain (i.e. XYZAWS ) for my organization named XYZ which has one-way trust with our on-prem AD i.e. XYZ domain.
Now here is the catch when we deploy .Net application with windows authentication enabled to EB (elastic beanstalk) our EB server is running in AWS domain i.e. XYZAWS and that EB server is not domain joined by default so you need to domain join your EB server first and this domain join will happen with you on AWS managed AD i.e. XYZAWS domain.
As EB is domain joined to AWS managed AD that won't authenticate your on-prem AD users for that you need to impersonate your IIS app pool with a user which is in your on-prem AD.
For example I am impersonating my IIS identity pool with user XYZ\service-account-user and as I said we have one way trust between AWS managed AD and on-prem AD so your application should now be able to authenticate on-prem AD users bcoz you app is running as on-prem AD service account.
You have to include domain name while logging into your application
suppose user John has to login to app then he must login with user name "XYZ\john" and his password to let app authenticate him.
I have this whole setup automated using .ebextensions config files.
If I ever write blog on this will update it here.
I want to secure admin panel of ecommerce website such that only trusted users get to access the login page. To avoid any malicious attempts like bruteforce etc.
Storefront and admin panel are hosted on different domains. Complete stack is hosted on AWS. Possible solutions I can think of are:
Using fixed static IP address is a possible solution but many of our employees access panel from mobile devices outside office, and many from different cities while on travel.
Employing WAF to restrict login attempts etc. can be employed. But again, possibilities are there for a non trusted user to hack into with dedicated efforts.
I am looking for some way with which any url including login page becomes inaccessible for non trusted users without using IP blocking strategy.
If you need tight security, these are my points for you.
make the admin website to a private website and make it available only via VPN.
use WAF to guard the website from malicious attacks
as #Daniel mentioned, adding multi factor authentication(MFA) is the best way to secure it further.
to make a website private via VPN, You can,
deploy the website instances and the load balancer on private subnets
setup a open vpn instance on a public instance
Setup open vpn login credentials for each admin
Hope this helps
two factor authentication with TOTP (note that NIST recommends against SMS strongly, and the rest of the industry should too) is probably the best way to do this without imposing undue burdens on the users. AWS ALBs can do some cool things with authentication these days (from cognito OIDC to full on AWS-style request authorization with signatures) , but none of those things amount to more than a password login.
While the VPN solutions are good, the common approach to what you're describing is a client certificate. Each user is issued a client cert which they store on their machine(s). An approved cert is required to access the page. This is also commonly called "mutual authentication."
I have a backend service, which I don't want to be expose, and also, just the employees that uses Gsuite oAuth should access.
Instead of exposing the backend and add the logic of oauth in it, I looked at the vouch-proxy project, which fits me very well (a proxy that redirects unauthenticated traffic to oauth login page and then, when a valid token is passed, it's redirect to the backend.
Before using this vouch proxy, do GCP has something built-in for it? Or another kind of setup that my backend service is not exposed?
Google Cloud provides the Identity-Aware Proxy (IAP) that would precisely fit your needs since it's integrating well with G Suite domain and can sit in front of your Load-Balancer.
I have setup Cloud IAP on a development environment (spun up with Kubernetes and using Let's Encrypt) and everything is working fine.
The setup is pretty basic for this app:
1) An API that has a number of REST endpoints and a persistent data store, in project A
2) A SPA front end app that utilizes said API, in a different project B
In my browser (tried Chrome and Firefox), I can authenticate my Google user in both apps via the IAP screen (by going to each domain in a browser tab), but once I try to use the SPA and it attempts requests to the API, I see the network requests 302 redirect to the Google IAP sign-in page.
Question:
Is there a header or cookie that needs to be sent over via the API requests on behalf of the user so that IAP allows pass-thru?
Note
I see these two cookies btw GCP_IAAP_AUTH_TOKEN and GCP_IAAP_XSRF_NONCE.
What's protected with IAP, "API" or "SPA"? If it's SPA, IAP should work as normal. If it's API, your best option today is to use https://cloud.google.com/iap/docs/authentication-howto to have SPA authenticate to API, and maybe also have it pass down https://cloud.google.com/iap/docs/signed-headers-howto so that API can separately verify the end-user's credentials.
Passing down GCP_IAAP_AUTH_TOKEN from SPA to API won't work, we strip that before passing the request to the end-user application for security reasons (in case the transport between the load balancer and the application is HTTP, just to make life a little harder for an attacker.)
We are going to integrate Dynamics NAV 2013 with PHP eCommerce and are planning to do this by dynamics nav web services. I know that to integrate with PHP I have to enable NTLM authentication, but I'm wondering if is it possible to publish web service which doesn't require login/password authorization?
Second thing, if I want to allow only specified IP's to access my web service, is it possible to do this in Navision or it's server administrators problem?
The client consuming a Nav web service has to be authenticated and mapped to a system user account, but it is possible to authenticate via the user name and the corresponding web service access key instead of the domain password.
Common approach is to create a user account that is used for web service access only, generate the web service access key, and pass this dedicated user's credentials from the consuming application. Client application will be required to provide the security certificate.
Besides, it is a good idea to create a separate service instance specifically for external access (usually users connecting via WAN).
Create a new Nav server instance and set ClientServicesCredentialType" = "NavUserPassword". How to configure authentication via NavUserPassword
Create a user account with Web Service Access Key: Use an Access Key for SOAP and OData Web Service Authentication
Setup security certificate for the web service: Implementing Security Certificates
Develop your application that will consume Nav web service, and pass the Nav user name and the web service access key instead of the password from this application.
This way, all users connecting from your web application will be authenticated, but they won't have to enter user name / password and you don't risk exposing your domain account credentials.
As for your second question - there is no way to setup this restriction from inside Nav that I'm aware of. I think this is a task for sysadmins - firewall applications allow you to setup very elaborate access rules.
No you can't disable auth (you able to select auth type other than ntlm though). And I believe there is no case in witch you shoud do this with Nav. Nav stores financial information so no-no-no you should not do this under any corcumstances.
No you can't restrict acceess by IP via Nav.