I've possible got to implement SAML for a couple of sites we have and I was wondering if this kind of requirement can be implemented in infrastructure technologies like Active Directory or do I have to implement the solution in application code?
Cheers
Ollie
I think ADFS supports this so you shouldn't have to write any code. Just do some configuration tweaking.
AD FS implements the standards based WS-Federation protocol
and Security Assertion Markup Language (SAML).
http://msdn.microsoft.com/en-us/library/bb897402.aspx
However, you might need to tweak some code based on how the domains and usernames are handled. For example, if the app just uses the username as a key and there's another guy in a different domain/directory with the same username then you'll have problems. If they use domain/username, then it would be less of a problem, but you might still have collisions based on how the user authentication and lookups are handled.
There are some commerical products provided by Ping Identity and RSA (EMC) that do some of the SAML work for you, too.
Note that I'm a dev and not a AD/networking guy (so I could be wrong about AD stuff), but I'll be working with this in the near future to integrate some of my intranet sites to our various sibling companies/divisions who are on different networks/directories.
Just to clarify, ADFS leverages the SAML token but is NOT interoperable with the SAML protocol. Since you need to support SAML for your websites, then you'd need to implement the same SAML protocol as your SSO partners will be using - either 2.0, 1.1 or 1.0.
We have a lot of info about SAML in the information library portion of our website: http://www.pingidentity.com/information-library/index.cfm
Of course, we also offer an simple and secure solution for these requiremetns - PingFederate.
Related
We're are about to build a new intranet system for our company, leaving SharePoint behind. The system will be built using Ruby on Rails. Since we're using Office365 for mail, calendar etc., we would like to authenticate our intranet users through Office365.
I'm aware of Microsoft Graph API, but I have a hard time figuring out of there is a possibility to authenticate users from a third-party application. Moreover, we would like to retrieve general information about the user, like profile picture and calendar information.
Is anybody knowledgeable about Microsoft Graph API and know if it's possible to achieve our goals using the API?
You're on the right track. You would authenticate with Azure AD, which is in the 365 ecosystem.
I wrote (and answered) a detailed guide here:
How to get the JWT (using OpenIdConnect) from HttpContext, and pass to Azure AD Graph API
Note that this is the OpenIdConnect flow. I think the Saml2 flow is somewhat different.
Don't take my advice on storing the authentication codes or try to acquire the token silently - it ended up causing issues in production that weren't seen in test. Rather, just use the user object id as your key attribute.
The microsoft documentation on the topic is a little cerebral and abstract, so it'll take a little head scratching, but have a look at the samples mentioned in the post I linked above, they'll get you started.
Yes, using Microsoft Graph is the right way to go about achieving the stated goals here.
There are quiet a few samples and tutorials provided on the Microsoft identity platform code samples page that will teach how to build an app that calls Microsoft Graph.
All of the MSAL documentation wants me to use a prefix such as msalGUID:/// when authenticating back to the local device.
Then there is the oddball url urn:ietf:wg:oauth:2.0:oob that appears by default in the MSAL portal.
Since every URL I list there is essentially a backdoor into my application, I want to understand the security benefit of each option.
Why should I use the documented msalGUID:// scheme?
Should I not use an iOS Universal Link / fully qualified URL?
What is the benefit of the urn:ietf:wg:oauth:2.0:oob, and https://login.live.com/oauth20_desktop.srf?
What should I be aware of w.r.t. interactions with Microsoft Authenticator, which likely depends on this?
Background
There's a few attack vectors & usability cases that come into play when considering the redirect URI your app will use.
First, is your app going to be signing in users from an authorization agent that is not sandboxed to your app. If you're using MSAL, then the answer is almost always yes (unless you have explicitly opted to use in-app WebViews).
Cases to consider
If so, then you have two cases to consider: accidental collisions of redirect URIs (usability issue) and malicious apps intentionally trying to intercept a user being redirected back to your app (security issue).
Case 1: Naive apps
To address the former, MSAL has chosen msal<ClientID>://auth as it's unique to each app registration. There's a high amount on randomness in this format (that is lost with urn:ietf:wg:oauth:2.0:oob) which prevents the scenario in which multiple apps on the device are listening on the same URI and "accidentally" get the response. For a user, this is extremely frustrating and would impact their experience with their app. To summarize the best practice to address this, use a highly random URI that avoids accidental collision with other apps.
Case 2: Malicious apps
To address the latter, MSAL implements the Proof Key for Code Exchange (PKCE) protocol to eliminate this attack vector. To expand on the scenario, it's similar to the above scenario, except for the app has captured the response intentionally and intends to exchange the authorization code on your behalf. With PKCE, only the app that initiated the request can exchange the auth code.
Summarizing answers
To quickly answer your bullets,
Covered above.
If you're familiar with universal links and how to setup the necessary steps, this may be a good option for verifying that your app registration is only used by you.
These are intended for apps using in-app WebViews where there's stronger security guarantees related to the fact it's not leaving the app.
MSAL does not currently integrate into the Authenticator to complete auth requests. When it does, apps will likely be required to complete an enhanced registration related to redirect URIs similar to ADAL's requirements.
I have some questions regarding Identityserver4 in the following context:
I have a number of domains (domainA, domainB, domainC ect.) and I’d like all of them to use Identityserver4 for authentication, but I’d like only one implementation of Identityserver4 (with asp.net identity and EF) and have the all domains use this implementation as clients. All domains is in a hosted environment with MS SQL as database, if that has any relevance.
Question 1:
Can IdentityServer4 run in a subfolder/area of domainA, and if so what are the necessary steps for getting this to work, e.g. the endpoints shown in the .well-known endpoint?
Question2:
What are the pitfalls, if any, in hosting Identityserver4 in a subfolder/area under domainA, and also having domainA use Identityserver for authenticating users for the rest of the site, and how to avoid the pitfalls if there are any?
The authorization part that permits one user to do this and not that, and the opposite for another user is not the concern of Identityserver4, but the respective domains/sites own responsibility as I understand what I can find online. In order to make use of roles and roleclaims in asp.net identity core 2 in each domain/site there has to be a user in that domain/site, that has a reference to a user in Identityserver4 in order for the domain to use Identityserver4 for authentication.
Question 3:
How do I avoid that the user must register both on the domain and in Identityserver4, one registration would be preferable and have the other made behind the scenes along with the reference?
I hope someone can provide the answers to one or all of my questions. Links to relevant blogs etc. are welcome, but I have scoured the web to find useful answers without any luck – hopefully some of you have better search engine skills than me.
Q1
Yes you can. IdentityServer is OWIN hosted environment, thus it will be working as a middleware for your domainA, if you set it up so. Having a public endpoint entirely depends on your domainA.
Q2
The possible problem you will possibly encounter would be performance issues. your domainA is going to receive requests from domainB and domainC including, of course, domainA itself. And IdentityServer's checks-up such as authentications, validations, issuing tokens could be obviously time consuming jobs compared to the plain HTTP requests.
While the middleware is doing its job, the performance will hit slightly lower rate then domanB and domainC. But this is a necessary, unavoidable backfire because you added one another layer in your HTTP windows to deal with the authentication / authorization / validation issues on your service endpoints.
You may want to scale out your IdentityServer if the traffic gets much more huger then you expected and you feel your authorization server is dragging the whole services down. I recommend you to perform some stress tests beforehand and compare the performance differences between the services using the identity service and the services using none of that.
Q3
This could be highly opinionated answer. But as you mentioned ASP.NET Identity and EF I think you already know the answer. It seems that you're going to manage the token and identity information in your own hosted DBMS. Then consider it done with the possible duplicated registrations. Your DBMS and your implementation for storing and fetching such data will do it for you as long as you've done it right.
If you're not going to use DBMS for the identity and token data, and use a cache or a file system instead, then you will have to pour some efforts into the implementation in order to guarantee concurrency on the transactions for such data.
I've created a website within the company that utilizes our active directory server to authenticate. I am concerned about security surrounding setting up relying parties with "localhost" domains.
I've pretty much followed this guide on setup. You'll notice about halfway down the page, there is a step to set up the development environment, localhost:44336 as a relying party.
I am concerned that someone could easily get the location of our federation metadata document, and simply roll their own project utilizing the same port and get access to our active directory. Is this a valid concern, or am I worrying over nothing? What would be a better alternative to having to use localhost in this configuration?
Yes it's safe. The metadata document only describes information about endpoints and about the token that active directory is issuing. It doesn't inherently have anything sensitive about it.
The actual authentication is still going to be handled by AD and unless the curious user already has a way to successfully authenticate against your AD then it's rather useless for him to hookup into that document.
Could they potentially create an app that uses your authentication protocol? Sure, but what would be the point if nobody can actually authenticate against it. Allowing this sort of behavior to happen is one of the points of ADFS.
I'm about to build a community platform from scratch. We are going to create the WebServices first and the community might have some third party components, so having solid WebServices is a good idea anyway.
Since the service is stateless we need authentication for every single call. Is it a good idea to implement the OAuth protocol for our service provider to perform this task although we are the only consumer right now?
By the way: We will deliver a mobile application before a website is launched.
The whole point of OAuth is to allow other websites (consumers) to get access to your data (you are the provider). Since you are the only consumer of your data, there is no need to implement OAuth at this stage of development.
Be lean, build something fast and put it in front of users/testers. Only at this point you will discover real bugs and get a feedback on the service so that you can improve it and steer the development in the right direction.
Note: OAuth as provided by App Engine (second paragraph) only supports users with Google Accounts (even if OpenID is used).
From my experience I created the REST WS in a authentication agnostic way: jersey methods accept everything, then there are several filters in order to validate the requests.
I used OpenId authentication for the web part, OAuth and BASIC AUTHENTICATION (with SSL) for API.
Probably it is not needed to create everything from the beginning, but remember to de-couple as much as possible your REST endpoint from the authentication: you will have a great benefit when you want to release APIs.
Last "philosophical" thing: OAuth is not totally stateless, in fact you have a temporary token that authenticates a user and it is similar to a session in the browser!