I have not previously put much thought into what the externally facing URL's of my services and apps and sites should be.
However, we are currently implementing a new single sign on architecture with a landing page, utilising OAuth and Open ID Connect. To achieve this, we are using IdentityServer4 with a federation gateway, an internal identity provider linked to out Active directory and an identity provider for a database for one of our existing apps. The identity provider for our existing app already exists with an external URL but none of the others are created yet. This means that externally I now have to create 3 new URLs
for the landing page site we are protecting.
The federation gateway
The identity provider for my active directory.
Are there any known naming conventions for the federation gateway and ad identity provider in order to not leave them vulnerable to attack from external sources, or am I worrying about nothing.
For example, if I use
www.[domain].com/federationGateway
www.[domain].com/ADIdentityProvider
Am I leaving myself open for someone finding these addresses, thinking "hang on that’s a link to their AD, or that’s their federated gateway" then bombarding them with a DDoS attack and bringing down my single sign on architecture.
Any guidance that anyone can give me would be gratefully appreciated.
Cheers
As a general rule, you should never allow directories to be publicly accessed if you don't want anyone to find them. You can protect them by adding a login to access them (I'm not sure if you've done this?).
In regards to your concerns about DDOS attacks, you have nothing to worry about. DDOS attacks affect the whole domain, not just a subdirectory. For example, someone that DDOS'ed www.domain.com/RandomPath/Stuff would bring down all of www.domain.com, not just the subdirectory. If you are worried about DDOS attacks, you can either buy a "stronger" server or install software to prevent against DDOSing.
To sum it up, you don't have much to worry about. Unless you are being specifically targeted, nobody will find your federation or AD directories. DDOSing will most likely not be a problem for you unless someone with a lot of resources starts to DDOS you.
Related
The Microsoft docs state:
Registering your application establishes a trust relationship between your app and the Microsoft identity platform. The trust is unidirectional: your app trusts the Microsoft identity platform, and not the other way around.
What exactly is meant by "trust" here and how does the app registration establish said trust?
The way I understand it the registration basically makes the app known to the AD, but how does that make the AD, the app is redirecting to for interactive logins, more trust-worthy to the app? Couldn't a malicious AD just pretend to know any app that's using it for logins? Wouldn't it need some kind of shared secret to assure the app that the AD really is the AD? And isn't HTTPS establishing that trust already?
It makes more sense to me the other way around: the AD receives a login request along with a redirect URI set by the app. But if the redirect URI is not known to the AD then the request is not trust-worthy and will be rejected.
I'm probably misunderstanding something, so could someone please explain the idea behind this?
In authentication world trust is a complicated word. In my opinion, the easiest way to approach this thing is taking the Google Sign-In -button as an example. You can use it to log in with your Google account on almost every website out there. Does this mean Google trusts every website out there using it? No, of course not. Do those websites trust Google? Sure they do, they have no visibility if Google returns the correct information about the users to them.
The case is very similar here as in most cases you will be using the same protocol to implement it (OAuth2 OIDC).
You are correct, you need to configure secrets & returnUrls to make sure that the App Registration is not used for malicious purposes, however, this does not create trust between the identity provider and the application. It's just technical measures to protect the client.
However, you can of course trust the application if you want to. The most common way is to grant it access to scopes so the application can do actions on behalf of the user. Usually this is done by those consent screens you probably know ("grant access to your email and phone number"). In enterprise setting, they are often omitted and access is granted with admin constent.
TL;DR; There is no inherit trust just because there is an App Registration, however you can trust an app to access user data.
Good afternoon everyone.
In the team we plan to make n applications that are very different from the others but we need that with a single time that the user authenticates he has access to all of them.
The applications will be under a single domain.
domain.com
app1.domain.com
app2.domain.com
app3.domain.com
So we want to implement an authentication scheme very similar to google's, where 2 additional subdomains are managed:
accounts.domain.com: to handle all authentication rules (eg login, signup, forgot password, etc.)
myaccount.domain.com: to manage all the user's personal information, subscriptions, security settings, etc.
The questions are as follows:
What is the safest and best way to do this?
What database-level considerations should we take into account?
What general considerations should we take into account to avoid
future problems?
For what it's worth, the stack we are going to use is nestjs + mongodb + graphql
Thank you very much.
The easiest and safest way to manage this is to use a proxy that accesses the services instead of the user directly communicating with them. Then they only have to authenticate against the proxy.
Your other options require some sort of central authentication provider. This could be done a number of ways (assuming you control all the involved services). You could use a shared cross domain cookie or use some sort of oauth flow depending on your requirements.
One of my requirements is to implement single sign-on for a set of sites. There is no need to support Open ID as usual nor become Open ID provider. However, I think about using Open ID internally. My questions are:
If my Open ID provider is limited to a trusted list of domains authentication experience will be transparent to users (except few redirects to the provider sub domain and back and bit different forms design)?
Since the provider is not public (a list of domains to check redirects against) there will be no new attack surface introduced?
If one of the sites has a desktop application should the application talk to the provider directly or via a facade of the site?
Found similar question which is useful but does not really answers mine.
1) Yes, the experience can be similar, but not seamless. For example, you might not be able to have username/password login box on the site.
2) The provider has to be accessible by the client (not just Relaying Party). So it depends on whether your clients are internal or internet.
3) It really depends on whether the application can do OpenID. Also, see (1), can the application handle opening up of the provider webpage?
I've developed a CodeIgniter project tracking app for a client which lives at a public URL but is used privately. It includes a simple REST API, used exclusively for a Dashboard widget and Cocoa menu bar app though it will grow later.
Originally designed for a small team, the app is going to be used more broadly within the (large) company. My plan to grow and secure it...
Evaluate traffic needs, project resource usage, and scale hosting accordingly.
Rely exclusively on HTTPS and purchase a decent SSL certificate.
Require authentication for the REST API.
Actively monitor for abuse and have a blacklist (or several) in place.
Are there any obvious issues that need to be addressed or best practices to follow for a private/public app such as this?
It's a rather broad question. There are several complicated facets.
SSL is good; think about enabling CI's CSFR protection
Lock down your server. Close ports like email and ftp if you don't need them. Google for tutorials or ask specific questions based on your OS.
A great guide of form-based auth stuff: The definitive guide to form-based website authentication
Make sure your permissions are how you want them. e.g. keep private things private. Design a policy for granting and revoking access.
So I like the OpenID idea. I support it on my site, and use it wherever it's possible (like here!). But I am not clear about one thing.
A site that supports OpenID basically accepts any OpenID provider out there, right? How does that work with sites that want to reduce bot-signups? What's to stop a malicious OpenID provider from setting up unlimited bot IDs automatically?
I have some ideas, and will post them as a possible answer, but I was wondering if anyone can see something obvious that I've missed?
You have confused two different things - identification and authorization. Just because you know who somebody is, it doesn't mean you have to automatically give them permission to do anything. Simon Willison covers this nicely in An OpenID is not an account! More discussion on whitelisting is available in Social whitelisting with OpenID.
The short answer to your question is, "It doesn't." OpenID deliberately provides only a mechanism for having a centralized authentication site; it's up to you to decide which OpenID providers you personally consider acceptable. For example, Microsoft recently decided to allow OpenID on its Healthvault site only from a select few providers. A company may decide only to allow OpenID logins from its LDAP-backed access point, a government agency may only accept OpenIDs from biometrics-backed sites, and a blog might only accept TypePad due to their intense spam vetting.
There seems to be a lot of confusion over OpenID. Its original goal was simply to provide a standard login mechanism so that, when I need a secure login mechanism, I can select from any or all OpenID providers to handle that for me. Allowing anyone anywhere to set up their own trusted OpenID provider was never the goal. Doing the second effectively is impossible—after all, even with encryption, there's no reason you can't set up your own provider to securely lie and say it's authenticating whomever you want. Having a single, standardized login mechanism is itself already a great step forward.
OpenId isn't much more than the username and password a user selects when registering for your site. You don't rely on the OpenId framework to weed out bots; your registration system should still be doing that.
Possible solution - you can still ask new IDs to pass a CAPTCHA test. Just like bots can sign up with fake/multiple email addresses to any site, but fail the "verification" step there as well.
Or are we going to have to start maintaining provider blacklists? Those won't really work very well, given how trivially easy it is to set up a new provider.
As far as I can tell, OpenID addresses only identification, not authorization. Stopping bots is a matter of authorization.
Notice that unlike conventional "per site" logins, OpenID gives you an identity that potentially transcends individual sites. Better yet, this identity is even a URI so its perfect for using with RDF to exchange or query arbitrary metadata about the identity.
You can do a few things with an OpenID that you can't do with a conventional username from a new user.
Firstly you can do some simple whitelist operations. If *.bigcorp.example are OpenIDs from Big Corp employees and you know Big Corp aren't spammers, then you can whitelist those OpenIDs. This ought to work well for sites that are semi-closed, maybe it's a social site for current and past employees.
Better though, you can make inferences from the other places that specific OpenID has been used. Suppose you have a map of OpenIDs to reputation values from Stackoverflow.com. When someone shows up at your web forum with an OpenID, you can see if they have decent reputation at Stackoverflow and skip the CAPTCHA or probationary period for those users.