I am wondering whether there are any major security concerns with providing metadata for SAML configuration on a public URL versus providing the IdP or SP with a metadata file. The metadata includes a public key for encryption.
If there are any security concerns what are they?
No, there are no security concerns in providing the metadata as a public resource.
Public keys will usually be provided in the metadata for verifying the signature (with the public key, the service provider - consumer - can verify that the SAML response sent by the identity provider has not been tampered with).
For encryption (optional in SAML), the service provider will need to send its public key to the identity provider. With the public key, the identity provider will be able to encrypt the response and only the service provider (with the private key) will be able to decrypt it.
It depends on security requirements of your organization.
If your organization doesn't want to protect public key material, then you can publish, allow unlimited and unauthenticated access to SAML metadata.
If your organization want to protect public key material, then protect the SAML metadata against unlimited and unauthenticated access.
As per Public Key Cryptography, public keys are meant to be freely shared between parties, but in this context, your organization's security team have to decide whether the public key material should be made available to intended party only or publicly available to all.
Related
Our .net core based web api needs to validate the the JWT access tokens received from third party but trusted AAD. In order to do that token signature validation our web api needs to have public certificate of trusted AAD. This functionality is in POC phase. So how to get/download public certificate (.cer file) of AAD?
I would recommend that you use the standard JWT Bearer authentication scheme which handles this aspect for you.
You specify the Authority and ClientId to it and it'll handle the rest.
But if you are curious about the details,
I can explain a bit.
First you take your authority, e.g. https://login.microsoftonline.com/company.com/v2.0 (or https://login.microsoftonline.com/company.com if you are using v1 tokens).
We add /.well-known/openid-configuration to the authority to get the metadata URL: https://login.microsoftonline.com/company.com/v2.0/.well-known/openid-configuration.
That metadata URL gives us JSON which includes the jwks_uri property.
E.g.:
"jwks_uri":"https://login.microsoftonline.com/tenant-id-here/discovery/v2.0/keys"
When we navigate to this URL, we get the public signing keys for Azure AD.
This is all handled under the covers by the JWT Bearer authentication handler though, so you should not implement it yourself.
Not an expert on the subject, I wanted to understand if a public key such as the one used for signing saml tokens by a STS such as ADFS can be retrieved on-demand automatically by a relying party server. Is anything like this possible or does the public key need be deployed manually to servers requiring it? Do standards like SAML allow embedding a URL in the saml token for downloading the public key when needed? Is anything like this simply a crazy idea from a security standpoint?
The ADFS keys are all in the metadata.
The metadata is always publically available via a URL.
In addition, the RP normally requires the metadata to do the initial config. on its side.
I am newbie in JSON web token and micro services. I read in an articles that if i share the private, all services can verify user on their own. Then i tried to implement an application to practice.
Basically, I have two services A and B. A is used for authentication. Then, I tried implement a API that required authentication in service B. But when I used a token generated by authentication A in API, 401 status code and "Invalid signature." were returned.
So anyone can explain to me what I did wrong?
"Invalid signature" implies that the secret key that you used to encode the token doesn't match with the secret key you used for decoding it.
Make sure that the secret you are using for encoding and decoding are same.
For more info visit the JWT's site.
First of all the service to service communication only need public key to be shared in case of an asymmetric key pair such as RSA or ECDSA. The public key shared can be used to verify the signature and each service needs to sign JWT using their private key. You have to take care of securing the private key and make public key accessible to other services.
Verifying the user is a completely different use case. The user existence should be checked in database and a password check can be made which is authentication is all about. The JWT can be used to pass the user information along with access right with a signature done by the application using private key so that no one able to generate the same token. NOTICE : Signature is done using private key. In this way you have both authentication and authorisation using JWT.
JWT OAuth2 Token is prefetched from Spring Auth Server and stored in Redis Storage.
I don't want to request access token in OAuth2RestTemplate and I want to use my JWT Token for requests.
Can I do it with OAuth2RestTemplate or I should use usual RestTemplate?
The documentation for spring-security-oauth is useful here, basically the two sections: JWT Tokens and Accessing Protected Resources:
JWT Tokens
To use JWT tokens you need a JwtTokenStore in your Authorization
Server. The Resource Server also needs to be able to decode the tokens
so the JwtTokenStore has a dependency on a JwtAccessTokenConverter,
and the same implementation is needed by both the Authorization Server
and the Resource Server. The tokens are signed by default, and the
Resource Server also has to be able to verify the signature, so it
either needs the same symmetric (signing) key as the Authorization
Server (shared secret, or symmetric key), or it needs the public key
(verifier key) that matches the private key (signing key) in the
Authorization Server (public-private or asymmetric key). The public
key (if available) is exposed by the Authorization Server on the
/oauth/token_key endpoint, which is secure by default with access rule
"denyAll()". You can open it up by injecting a standard SpEL
expression into the AuthorizationServerSecurityConfigurer (e.g.
"permitAll()" is probably adequate since it is a public key).
To use the JwtTokenStore you need "spring-security-jwt" on your
classpath (you can find it in the same github repository as Spring
OAuth but with a different release cycle).
Accessing Protected Resources
Once you've supplied all the configuration for the resources, you can
now access those resources. The suggested method for accessing those
resources is by using the RestTemplate introduced in Spring 3. OAuth
for Spring Security has provided an extension of RestTemplate that
only needs to be supplied an instance of
OAuth2ProtectedResourceDetails.
This basically means to me that you'll use the same spring-security-jwt JwtAccessTokenConverter class in both the authorization server and the resource server and that the token services in each need to be setup with the JwtTokenStore(). The extension to the RestTemplate class they're referring to is the OAuth2RestTemplate from spring-security-oauth2. You'd use it in your resource server with it's JWT smarts being provided by an equivalent token recognizer.
Because the spring-security-oauth2 code is already set up to handle JWT tokens, you just need to provide a few key pieces and let the framework do the heavy lifting of inspecting the token and putting the security into scope for each protected resource.
As it would happen, someone's posted a nice example of this which goes into detail: baeldung spring-security-oauth-jwt example and here: github project of the same including how one could provide a more customized JWT (claims/payload).
I am trying to understand the SAML 2 protocol and in that process got a little bit lost with the signature and certificate business.
Basically, I am not clear of when each of the certs are used.
Service Provider Meta Data and Identity Provider Metadata - do we need to generate certificates/keys as a part of the SP and IDP metadata? If so how/when will these certs be used?
HOK token also needs a certificate - when does that come into picture? Does the principal's certificate/public key needs to be exported to the IDP also along withe SP's certificate?
When using bearer tokens (they do not have any certs associated with the principal) is the SAML response/assertion still signed? Is it different from the ds:keyInfo in the SAML response in this case?
Thanks a bunch for the help!!
1.
Certificates in SP and IDP metadata are typically used for two purposes digital signing and digital encryption. Attribute "usage" on metadata makes the discrimination. Certificates are typically included in the metadata, but they could also be ommited and provided out-of-band (e.g. by direct configuration in IDP and SP, if supported). These keys identify the SP and IDP machines, they have nothing to do with the users.
When SP sends a SAML message towards IDP the message can be digitally signed using SP's private key (whose public key + certificate is included in the SP metadata and available to IDP), IDP is able to verify the SP's signature using the SP's public key.
When SP wants to encrypt part of the SAML data (whole message, assertion, name ID, attribute, ...) it uses public key declared in the IDP's metadata, IDP then decrypts the data using its private key.
Sometimes metadata can contain multiple signing or encryption keys, e.g. in case of certificate rollover before expiration.
2.
Bearer mechanisms are used to make sure that the entity (e.g. web browser) who is presenting a SAML message is allowed to do so. In SAML WebSSO AuthnResponse message gets issued by the IDP, but is delivered to the SP by the browser. HoK SubjectConfiguration tells that we are identifying the presenter by making sure that it can prove posession of a private key whose public key/certificate is included in the SubjectConfirmation element. This is typically done by usage of SSL/TLS Client Authentication (i.e. user installs private key in browser and uses it to authenticate toward SAML service when opening the HTTPS scheme with SSL/TLS).
So here we are dealing with keys issued directly to users, not to SP/IDP services. Whether or not you need to import user's certificate(s) to the IDP or not is IDP-implementation specific.
3.
Yes, the messages will still be signed (when configured to be) and KeyInfo in the SAML response will be the same in both cases.
Cheers,
Vladimir Schafer