One of our client had certification rollover at their adfs implementation. After that they are no longer able to login.
The main question we are facing is, before this rollover we never used certificates in our saml authentication.
We have set expressjs with passport passport-saml and we never use any cert for it. It was working before but now it got stopped.
I searched and found that at our end we need to updated the certificates received from federationmetadata from their adfs.
Questions:
Any possible reasons why it might have stopped working ?
How was it working before without certificates if we need to update certificates now ?
Related
I'm becoming mad trying to set up ADFS authentication for Sharepoint. The error I'm getting is:
Ensure that the SecurityTokenResolver is populated with the required key
The error is thrown by /_trust/default.aspx that is the endpoint where ADFS redirects after successful login and clearly states that the certificate I've used to create New-SPTrustedIdentityTokenIssuer and also imported as SPTrustedRootAuthority for the whole Sharepoint is not trusted by the certificate used by ADFS for Token-Signing and Token-Decrypting mechanism.
I've tried with my own certificates from a CA enroled to AD and with a commercial one. I've verified that thumbrints correspond in both sides, SPTrustedIdentityTokenIssuer/SPTrustedRootAuthority and ADFS side.
Need some help here before going completely crazy.
Many thanks.
Resolved.
The certificate must be exported from ADFS Token-Signing one. This is the one you want to use for the client side. In this case Sharepoint SPTrustedIdentityTokenIssuer.
We currently only use reference tokens as access tokens. This has me wondering if we could just skip the entire certificate management hell by including a self-signed X509 certificate with a ridiculously long validity and store it with our source code (private github) - stop screaming, this might make sense soon.
The worst case I see would be that someone with access to the private key (i.e. any employee or force with access to our github repository) could issue any JWT and use that in the client (angular) - but that's client-side. The APIs are protected via IdentityServer Access Token Validation and all clients are configured to use reference tokens.
Another possible pitfall would be if we ever added a client that uses JWT for access tokens, but I don't really see that happening.
To me, using a long lived self-signed certificate under source-control seems to be the easiest and okay(-ish) solution for this case - unless I've overlooked something. We would never do that with SSL certificates or similar. I'm focussing only on the IdentityServer4 signing credential in combination with exclusive use of reference tokens.
Otherwise we'll have to somehow get certificate rollover (at runtime), certificate management etc. running. I guess we could implement ISigningCredentialStore to manage where the certificates are loaded from - but that still leaves us with the issue on how to handle certificates in a Docker swarm (or just plain Docker containers).
Am I missing something here? Would this solution have any flaws?
Could you not just look it up?
like this
var cert = new CertificateService().GetCertificate(appSettings.CertificateName, StoreName.TrustedPeople, StoreLocation.LocalMachine);
services
.AddSigningCredential(cert);
I have a .net WEB API publicly exposed and also a Xamarin Forms App which uses the API, the app needs to be extremely secure due to the data it manages.
I will create an HTTP Certificate for the WEB API.
The Xamarin Forms app will have a login/password to validate against a local Active Directory. via a /token endpoint, and using an Authorize attribute on all endpoints to assure that every HTTP call has the bearer token in it, I implemented that using this:
I based my implementation on this one:
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
Additionally the customer has asked us for Client Certificate Authentication, I dont understand how this totally works.
1. I need to add a certificate to the Xamarin Project, right? How do I Add it? How do I generate it?
2. In the Web API I need to validate each http call has the certificate attached.
I found this but not sure if it will work:
http://www.razibinrais.com/secure-web-api-with-client-certificate/
However when investigating this, I also found something about certificate pinning, which is basically security but the other way around, it means the Xamarin APP will validate if the server certificate is associated with the right server (or something like that), so there is no way of a MAN IN THE MIDDLE Attack.
I found how to implement it here:
https://thomasbandt.com/certificate-and-public-key-pinning-with-xamarin
Question is:
1. Do I need both ?
Something else that I should research for on this journey?
Certificate pinning and Client Certificate Authentication are 2 very different things. Certificate pinning makes sure your app is talking to the server it expects to talk to. It also prevents eavesdropping, which is known as a 'Man in the middle' attack. I just recently wrote an article about this on my blog.
Client Certificate Authentication works the other way around. It adds an extra layer of security so your server can be sure only clients that have the certificate can communicate successfully with it. However, since apps can be decompiled without a lot of effort, this client certificate can 'easily' be obtained by a malicious user. So this isn't a silver bullet.
From my experience, Client Certificate Authentication is often used in enterprise apps, when there is an Enterprise Mobility Management solution in place (eg. Mobile Iron or Microsoft Intune or others), where the EMM solution can push the certificates to the users device out of band.
Should you use both? That really depends on the requirements of your customer, since they mitigate 2 very different problems.
The Web API link you included looks like it should do the server job properly at first sight. This article also includes how to generate a client certificate with a Powershell command.
Generating a client side certificate:
Use the Powershell command in the article that you referenced in your question.
Otherwise, this gist might help you on your way.
Installation:
Add the certificate file to each platform specific project as a resource. This is usually done in the form of a .p12 file.
Usage:
That all depends on which HttpClient you are using.
If you use the provided Web API solution, you should add the certificate contents as a X-ARR-ClientCert header with each request.
I'd like to preface this by saying that until now, I hadn't even HEARD of SAML, much less developed a SSO strategy involving it. That, combined with the fact that I've barely been doing node for a year makes for a glorious newbie sandwich. Currently, I have a client who uses SAML and ADFS as their SSO provider. I am already using passport.js for local logins, so using passport-saml seems to be the way to go to implement the SSO using SAML/ADFS. In doing my research, I've found a couple different implementation guides, but since I literally know NOTHING about this process, I could use a few pointers.
In the passport-saml documentation, I found the following for a strategy proven to work with ADFS (according to the docs):
{
entryPoint: 'https://ad.example.net/adfs/ls/',
issuer: 'https://your-app.example.net/login/callback',
callbackUrl: 'https://your-app.example.net/login/callback',
cert: 'MIICizCCAfQCCQCY8tKaMc0BMjANBgkqh ... W==',
identifierFormat: null
}
I suppose my main question is where does this cert come from? Is this a cert I generate on my server via SSL? Does the provider provide it?
In my searching, I have also found this: https://github.com/auth0/passport-wsfed-saml2, which is based on passport-saml. The following configuration is suggested for ADFS:
{
path: '/login/callback',
realm: 'urn:node:app',
homeRealm: '', // optionally specify an identity provider
identityProviderUrl: 'https://auth10-dev.accesscontrol.windows.net/v2/wsfederation',
cert: 'MIIDFjCCAf6gAwIBAgIQDRRprj9lv5 ... ='
}
In this example, the path object is obvious, and my provider has already given me an providerURL. But realm makes no sense to me, and there's that darn cert again.
Could someone provide me with an "explain-like-i'm-five" way of implementing SAML/ADFS SSO in a node.js site? Or help me make heads or tails of the argument objects requested by the two solutions I've outlined? Much appreciated in advance!
I recently went through the same thought process: having never heard of SAML, I needed to enable a web application to authenticate via SAML with OneLogin as the identity provider (instead of Active Directory).
During implementation, I made heavy use of OneLogin's documentation and the passport-saml library, both of which I recommend, though I'm not affiliated with either.
What I came to realize was that the confusion was three-fold:
(1) how SAML works,
(2) how the passport-saml library works in Node, and
(3) how to configure the identity provider (OneLogin, Active Directory, or otherwise). What follows is my attempt at an "explain-like-I'm-five" explanation.
SAML
Security Assertion Markup Language (SAML) is an XML standard that allows users to log in based on their browser session. There's a lot to it, but basically, it enables a simpler authentication process. A user can click a button rather than submit a form with username and password.
The way SAML works is a little more involved. I found this overview from OneLogin and the accompanying diagram helpful:
The diagram represents the following process:
User clicks a button to authenticate for a given application (sometimes called service provider) using SAML. A request is made (to Node or otherwise) to build a SAML authorization request.
An authorization request is constructed. This authorization request is XML (see more on OneLogin), encoded and/or encrypted, and appended to a URL as a query param. Node redirects the browser to this URL (something like https://domain.onelogin.com/trust/saml2/http-post/sso/123456?SAMLRequest=...encodedXML...).
OneLogin, as identity provider, determines from the browser session whether the user is already logged in. If not, the user is prompted with OneLogin's login form. If so, the browser POSTs a SAML response back to the application (service provider). This SAML response (again XML) includes certain properties about the user, like NameID.
Back in Node, the application verifies the SAML response and completes authentication.
Node and passport-saml
Passport.js is authentication middleware for Node. It requires a strategy, which could be something like passport-local or, in our case, passport-saml.
As the passport-local strategy enables Passport authentication using username/password, the passport-saml strategy enables Passport authentication using the browser session and configurable identity provider values.
While passport-saml served my purposes really well, its docs were difficult to reason through. The configuration example doesn't work due since the OpenIdp identity provider is inactive and there are lots of configurable parameters.
The main one I cared about: entryPoint and path (or callbackURL). I only needed these two, which do the following:
entryPoint is the URL to redirect to with the authorization request (see #2 above).
path/callbackURL set the URL/route in Node for the SAML response to be POSTed to (see #3 above).
There's a ton of other parameters that are important and valuable, but it's possible to configure SAML SSO using just these two.
Identity Provider configuration
Finally, the identity provider itself needs to be configured so that, given a SAML authorization request, it knows where to send the SAML response. In the case of OneLogin, that means setting an ACS (Consumer) URL and an ACS (Consumer) URL Validator, both of which should match the path/callbackURL configured for passport-saml.
Other things can be configured (to support logout and other features), but this is the bare minimum to authenticate.
Summary
There were two parts to the original question: (1) how to implement SAML/ADFS integration and (2) high-level SAML node.js implementation guide. This answer addresses the second.
As for specifically integrating with Active Directory, I recommend passport-saml's docs on ADFS, keeping in mind that there's two parts: configuring passport-saml to use an ADFS identity provider AND configuring your ADFS server to respond back to Node.
I could be wrong here but I believe it comes from the ADFS servers XML found at https://servername/FederationMetadata/2007-06/FederationMetadata.xml.
Pull out the X509Certificate. I have the same issues going on and I'm going to try that next.
As for the first part of your question, the certificate comes from the provider. Please have a look at the passport-saml documentation.
Simply pull out the Identity Provider's public signing certificate (X.509) and make sure to format it to the PEM encoding. The correctly formatted PEM-encoded certificate will begin with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----.
I'm setting up a server so that only mapped certificates can get to the webservice. It is set to require SSL/Client certificates, anonymous authentication, asp.net impersonation, forms authentication, and windows authentication are all disabled. One-to-one client certificate mapping is enabled, and certs are set up on the box with an appropriate user mapping. When I try to use the webservice, I get 401.2. If I enable anonymous authentication, it works, but I don't want any old cert to be able to access the website.
I have another machine that has anonymous authentication disabled in this configuration, and it works. I'm not sure what the difference is.
I ran into the same problem, but the solution above did not solve my problem. I was configuring IIS Certificate Authentication on a subdirectory of the website, not on the website itself.
So, this is wrong:
And this is correct:
Once I moved the configuration to the root of the website, everything worked perfectly.
I found the solution at http://blogs.msdn.com/b/saurabh_singh/archive/2009/06/13/avoid-this-confusion-around-client-certificate-mapping-in-iis-6-0-7-0.aspx.
Did you issue your client certs from a Certificate Server that the clients/server trust? If you look at the "Enhanced Key Usage" property on the certificates, is "Client Authentication" one of it's properties? In IIS, is the client certificate mapping role installed (see image 1)? did you enable "Client Certificate Mapping" and map the users to the certificate? You need to import all of the client certificates and map them to user accounts here. You can remove all of the other client authentication methods when you have configured that here.
The problem ended up being the software that was calling in, not in the configuration. I'm awarding natemrice the bounty since he put in a good effort to answer what ended up being a non-question.
edit: For more information, it actually ended up being a mismatch between the cert being sent (from the local box) and the cert that was put in the oneToOne mappings. The common name was the same, but the certs were different (likely the first one expired) so the cert simply wasn't authorized.