In part 1 of 2 in this blog I addressed the basics of extending ADFS. In this blog (part 2 of 2), I will cover some of the more important questions that should be asked prior to setting out to building your own Identity Provider (IdP) / Security Token Service (STS) or Attribute store vs. purchasing a supported solution from a 3rd party vendor.
Questions to ask yourself:
- Does your company/firm want to maintain custom development for security related operations? Typically this is not a good practice. If you do, you need to ensure that you do it right and make sure that the code you develop can be reused within the company for other uses so you have some sense of standards. An STS should be robust and configurable to handle the entire companies authentication needs, otherwise you have one-off’s.
- Is your company opposed to purchasing 3rd party software products? For some folks this is the case, and for some it’s because of cost. Just keep in mind the full cost of your time and effort to design, develop and maintain your solution vs. buying. In many cases, the cost (tangible and intangible of developing) far out way that of purchasing.
- Does your company/firm have the knowledge to development and maintain security software? If you are a business application developer, then spending your development cycles writing security software may be a waste of your expertise/time.
- Do we need to deliver a solution that scales and performs for all users? If so, you will need to factor in features that may become a burden if you haven’t done them before, such as maintaining LDAP connection pools. It is not feasible to scale creating and destroying connections for every authentication.
- Do we already have expertise in federation? If not, then you will be spending many days/nights researching terms and trying to figure out all of the many moving part within federation. Microsoft’s WIF does make the task of building an STS somewhat easy, but if you don’t understand what it does under the covers, then you will have a difficult time trying to customize your solution to meet your business needs.
- How many Relying Parties do you need to support? If you plan to deploy your STS along with ADFS, then this may not be an issue. Otherwise, if you have more than one (or plan to have more than one), you will need to factor that into your design and configuration utility. Will you build a configuration utility or make it hard to install/configure/maintain?
- Do you need to encrypt your assertions or just sign them? In either case, you’re going to have to know the difference and how to implement them. When signing, you need a certificate with the private key. When encrypting, you only get the public key from the RP.
- Do you need to support the FederationMetaData.xml file? This is built into WIF, but maintaining it can be a chore (especially when working with certificates).
- Do you need to implement a proper sign-out process? This is available in WIF, but the process of signing users out of ADFS (as an RP) vs. signing users out of other RP’s is different and can be quite tough to get right. The secret here is the ensure that you have given enough time to properly call the sign-out process in all of the places that your users are logged into (yes, you will need to track this yourself).
- Do you have the free time on your hands to actually complete this development effort? We have seen several people come to us after spending significant cycles in research and development for various reasons.
- Do you have any authentication method planned out or will you be attempting to support many different types? Such as: User/Pwd, Integrated, Certificate, DoD CAC-Cards, Open ID, Custom SSO, etc. If you are able to nail down one or 2 of these, you’d be better off, but when designing you have to plan for the future.
- Speaking of design. Will you develop a formal design document?
- Do you have any auditing requirements? If so, you really need to spend some time detailing out what it is you need to audit and where you plan to store the data. Make sure the auditing is running on a separate thread from your login process to avoid any slowness in processing authentication.
- If building custom, do you know how to build code that is not vulnerable to penetration testing, denial of service attacks, or cross-site scripting attacks? Do you know what these are? Have you ever developed code that has been tested under these scenarios? Remember, since your code is handling authentication and has access to user id’s and passwords security is paramount. Can you afford a data breach such as Linked In where 6 million account passwords were compromised?
- From an organization standpoint, what happens when the developer (maybe you) leaves the company? Many developers want to develop “cool” things and you may be that person so you may be biased. What is right for the company?
Finally, make sure you consider the following items as well if you plan to develop your own STS:
- Timeouts & Token Sessions (including sliding scale tokens & cookie paths). Do you know that these are?
- Make sure your sign-out page is not a protected page (in case your STS token expires prior to your RP token)
- Encrypt your connection information (passwords in your configuration files, etc.). Don’t forget to factor in the time it will take to develop a solid encryption mechanism. Remember this server is performing authentication and vulnerable to opening up security holes.
- Ensure that you are handling byte arrays properly from LDAP. For example, if you are working with AD/AD-LDS attributes such as the “objectGuid” or “objectSid”, remember to handle converting these values properly (Sid’s are converted/formatted differently than other byte arrays).
- Make sure you fully understand all the query-strings in play in federation and how to handle them. Note that some of the query-string values have query-strings themselves.