I would like to have your mind about an implementation. Thank you in advance for any suggestion :)
**Scenario**
I have a set of APIs. They are accessible via REST and protected by OAuth2. I have also a list of machines that needs to access them.
Question
On machine’s side, which is the best solution to access them? Should I implement a client certificate authentication or OAuth2 is a suitable solution?
**My doubts:**
In case of hundreds, thousands of machines, the certificate
management become too complex/costly?
Should I use a certificate for each machine or one certificate for more than one?
How can I deploy smartly the certificate to each machine?
I like the idea to have the mutual authentication, but I’m afraid is to heavy to maintain compared to the OAuth structure. I plan to use Microsoft Azure as cloud service.
Thanks!
I would say the important factors here are client identity and privilege:
You may have many client machines
But do they represent a single identity, eg a cluster?
And do they all have the same privilege?
By default I would aim for a solution where all client machines with the same privilege present the same credential / identity. The APIs can then authorize requests based on the client identity, provided in the access token.
The standard OAuth solution is Client Credentials flow, where clients each send a secret to the server.
If required (and supported by your Authorization Server) you can use a Mutual TLS form of Client Credentials, via the Client Assertion Profile. This usually boils down to a private key signature sent by the client, which is contained in a whitelist configured on the Authorization Server.
I need to generate a authentication token to secure stream from the Wowza CDN. I like to do this in server base javascript. I'm working on Domino 10 xpages server and working with videojs. Looking for how to get started and any sources that would help.
The Wowza authentication token seams to be an Hash hmac of the information that is needed to authenticate the user.
According to this
https://www.wowza.com/docs/protect-a-wowza-cdn-on-fastly-stream-target-with-token-authentication-in-wowza-streaming-cloud
This is an example how to create these using Javascript
https://www.jokecamp.com/blog/examples-of-creating-base64-hashes-using-hmac-sha256-in-different-languages/#js
I am integrating an application with LDAP in my organisation.
I am implementing HTTPS to send the password from the frontend to my application server, and then forwarding the password from my application server to the LDAP server using TLS. This keeps the password safe in transit.
However there is still the problem that my application server is still able to see the password in plaintext before it forwards the password to the LDAP server.
If I hash it on the front end then the password will not match the password on the LDAP server.
Is this a risk that I need to accept in order to integrate my application with LDAP? Or am I implementing this incorrectly somehow?
My application server is a python flask application and I am implementing LDAP3.
Thanks in advance.
For the question:
Is this a risk that I need to accept in order to integrate my
application with LDAP?
Yes.
The use of SASL Mechanisms which are supported by most LDAP Server Implementations can SASL authentication, this is However, this requires the LDAP Client (DUA) to be able to present an encoded value that contains the SASL mechanism name and an optional set of encoded SASL credentials.
Maybe you could use SASL with a ServerLess Architecture?
Regardless of the technology implemented, any password based authentication would require the user providing credentials which, at some point need to be gathered and therefore subject to this risk.
THe use of OpenID Connect could limit the exposure so the to the OpenID Provider's Authorization Server; but the risk is still present.
WebAuthn eliminates passwords and may be an option.
-jim
I am confused about different protocols and mechanisms for Kafka authentication.
Similar to this question here:
Can Kafka be provided with custom LoginModule to support LDAP?
I have kind of made my own PlainLoginModule that uses LDAP to authenticate the username/password provided by the client.
Is there any way for me to make this more secure? It does not seem safe to send plaintext passwords for the authentication. I would also prefer to not use plaintext password in the client side jaas file if possible.
If I were to use SSL could I still use LDAP server to authenticate? How would the kafka configuration change. Current conf:
listeners=SASL_PLAINTEXT://:9092
advertised.listeners = SASL_PLAINTEXT://kafka:9092
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.mechanism.inter.broker.protocol=PLAIN
sasl.enabled.mechanisms=PLAIN
You have two options how to make it more secure:
Use SASL_SSL listeners to wrap the SASL authentication into SSL encryption. You will still be able to use your LDAP through custom module.
Use one of the more secure SASL mechanisms. PLAIN mechanism will send the password over the network which is not secure. You can instead use one of the supported SCRAM mechanisms which will not send the password over the network and will use a more sophisticated handshake instead. Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512. However the SCRAM mechanisms would not work with LDAP - they store the credentials (not directly passwords) in Zookeeper. The SCRAM mechanisms can be of course also combined with SSL.
Yes you can use a SASL_SSL listener. This will use SASL to authenticate and then encrypt the data sent using SSL. If you want more secure authentication, you should consider using the GSSAPI SASL mechanism. ldap and Kerberos integration is a common practice and then you don't have exposed credentials.
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-----.