I am new to OneLogin setup. I need to test a SAML connection with encrypted/signed assertions from one login to our development server
What are the steps involved with generation of public/private keys and setting this connection?
You don't provide the private key for encrypting the SAML response. The SP provides you with a public key of their private key pair in the form of a cert. You then configure the Onelogin application to use the public key they give you.
Just to be clear, encrypted and signed are different things. You need to sign the SAML response, but you don't need to encrypt it. You can have both. If you just need the SAML response signed, then that's all handled for you in the OL UI.
Related
i am working on an authentication system that has access and refresh tokens and JWT and JWKS. my problem is that i don't know what is the functionality of JWKS. what is the functionality of JWKS in a authentication system that is working with JWT and refresh token and access token? what are public and private keys in this system? does JWKS need to connect to database?
Do you mean JWKS or a JWKS endpoint?
JWKS is JSON Web Key Set - a JSON notation for sharing public keys which are used to verify the signature of a signed JWT.
JWKS endpoint is an endpoint exposed by the Authorization Server from which you can obtain a JWKS.
Whenever you need to work with a content of a JWT (e.g. so you have an API which receives the JWT and need to perform authorization decisions) you should verify the signature. In order to verify it you need a public key, which corresponds to the private key used by the Authorization Server to sign the JWT. This public key can be obtained in different ways (e.g. you can hard code it in your API) and getting it from a JWKS endpoint is one valid way. If you have an option of reading public keys from a JWKS endpoint I would recommend to use it - this simplifies greatly key management in your system. Whenever you need to rotate keys, you just change them in the Authorization Server. It's especially useful if you do not control the Authorization Server - then you don't have to worry about keys rotation at all.
You can have a look at the second part of this free course: OpenID Connect in Details (requires email registration). The JWKS topic is covered there.
As documentation of NestJS for authentication using Passport JWT, the flow is as below:
Client login with username/password
If username/password is valid, JWT sign payload (use preconfigured secure key) to create access token and return this access token to client
Client use access token to request guarded resources
So if secure key to sign payload is hacked, the access token can be generated for ALL users without using password.
Is my above understand is correct? What is suggestion for more secure?
Thank you.
Yes, if the key is compromised, the attacker can generate keys for themselves.
Try to adopt a more secure storage for credentials. If it has some sort of key rotation mechanism, it would be even better. For example, I use AWS Secrets Manager for this purpose in my project.
I have some idea about OAuth token and used it in my last project. We used to store roles inside it so that resource server (WebAPI) does not have to request any more data to taken any decision on the authorization. Although authorization was based on permissions (that were mapped against roles). And resource server stored the mapping between role and permission.
In my current project, we are planning to use Azure Active directory. But in this project, we need to store one custom field and this field is the basis of all authorization model (along with roles). Although, in AAD (azure active directory), you can have custom fields but these fields cannot be sent in the form of claims.
So, my resource server will have to request this field for every user, once it receives the token from the client application. It can obviously store this in the cache for further request. But this does not look natural to me.
I believe, all the required for authorization should be part of OAuth token.
Please share your thoughts.
Not particulary for AAD , But if you want to keep everything in token then for sure You MUST encrypt the token. Considering that you are encrypting the token, There are three approaches that come to my mind:
Simple one, Authz Server encrypts the token with some private password. On arrival of token on Resource Server, it sends the token to Authz Server for validation and contents (Introspection API or OpenID Connect like API)
In next two approaches, Authz Server encrypts the token and RS decrypts the token locally.
When you register the Resource Server, Register it with public key of Resource Server (RS has Public and private key pair). Authz Server generates a random password to encrypt the token payload. Random password is ecrypted using the public key of Resource Server and added to JWT token header. Now when token reaches RS, it first decrypts the password using private key it has and then it uses that password (symmetric key encryption) to decrypt the payload. Everytime a new password needs to be generated to make sure that attacker sees new encrypted String everytime.
Similar approach as above, Here when Resource Server is registered (RS must be online) with public key of it, Authz Server contacts the RS and does SSL kind of handshake and they both exchange a long term session key which might actually last for 1 year or more (depending on security constrains of Your enterprise). Then when authz server generates the token, it encrypts it with session key and this time it doesn't add the session key to token header. Token goes to RS, RS check if it has a session key, if it has it tries to decrypt the payload using same session key. For error avoidance, RS can store the validity of Session key as well.
Azure AD doesn't support customizing the claims issued in the token.
However as a workaround, you can add the custom claims by querying Azure AD Graph in you project after the token is verified.
Here is a helpful article about Extending the Azure AD directory schema with custom properties.
I have various microservices. I have implemented security using JWT. Each service validates the JWT token by the key which is being shared across all the services.
Is it fine to share same signature key for JWT across all the microservices?
I can't implement this at the API gateway as I have to use certain libraries which requires spring security to be triggered in every microservice.
Yes you will need to share a key in order for JWT to function securely/correctly.
What I would recommend is using a public-private key signing method and pass by value JWT. This will then mean you get a private signing key which only your gateway needs to know and a public verification key.
You can then distribute your verification key to all your microservices. This can either be something you do via deployment, or your microservices can use some kind of refresh cycle and publish your signing key along with the gateway. The former is more secure, the later better at self healing.
This might be useful: JWK.
I want to implement saml using passport module of node js using my own idp. But the below links that i found are using some openidp/adfs/shibboleth etc.
https://github.com/bergie/passport-saml
https://github.com/lmarkus/passport-saml-encrypted
https://www.npmjs.com/package/saml2js
I have created two localhost apps ,one functioning as sp(service provider) ,other as idp(identity provider) and while redirecting from sp to idp i am sending the encrypted saml and than i am validating the user using passport ldap module,but i need to know that whether the certificates/public/private key needs to be present at idp side also ? How will idp send back the response and in what format ?
If you are signing the AuthnRequest or encrypting the token then the IDP needs the public keys.
The SP needs the IDP token signing public key.
The IDP will send back an AuthnResponse which contains the SAML token which contains the assertions (claims).
The easiest way to see this is to use the Fiefox SAML tracer add-on.