I want to create a web cloudFront distribution that can be accessed only using signed URL's.
On creating the distribution manually, there is an option Restrict Viewer Access under the Default Cache Behavior Settings.
I want to create the distribution using the serverless framework but I can't find the CloudFormation attribute for the Restrict Viewer Access property.
The documentation is totally not clear on this one. If the signing keys are in the same account you are deploying the CloudFront Distribution to you just need:
TrustedSigners:
- self
Note sometime in late 2020 CloudFront provided a way to create signing keys that does not involve using the AWS account root user. See these docs for more information. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html#choosing-key-groups-or-AWS-accounts
Little late on this. Adding to the above answer.
There are two ways to do it through CloudFromation.
TrustedKeyGroups - A list of key groups that CloudFront can use to validate signed URLs or signed cookies.
TrustedSigners - A list of AWS account IDs whose public keys CloudFront can use to validate signed URLs or signed cookies.
When a cache behavior contains TrustedSigners or TrustedKeyGroups property, CloudFront requires signed URLs or signed cookies for all requests that match the cache behavior. This is already assumed by CloudFront through these settings so you don't need to specify any other property(Restrict viewer access on UI).
As per AWS, They recommend using TrustedKeyGroups instead of TrustedSigners.
AWS URL: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-cachebehavior.html#cfn-cloudfront-distribution-cachebehavior-trustedsigners
Related
I have an API service that is currently secured using JWT. I'm going to replace JWT with Identity Server 4 and secure my API with Identity Server 4. I had a custom way of generating JWT tokens (JWE). How can I replace JWT with Identity Server 4 without the current signed-in users to the site need to re-login?
Specifically, I wanna use the Skoruba Identity Server 4 project template.
In IdentityServer, the access tokens are generated to authenticate users. The Access tokens have very small limited lifetime as per convention. There's a concept of refresh token which has longer lifetime and the same is used with basic auth to get new access token. This prevents the hassle to sign in again and again.
The refresh tokens are built using a hash and are persisted in a table (if configured).
JWE is a very different setup altogether. I had my users logged out even after a new deployment of IdentityServer4 (using of persistent grants is helping to solve this).
I don't think it's not technically possible to transfer sessions from one environment to another. Both use a encryption decryption strategies which are very different from each other.
You can give a try by writing a custom implementation of TokenCreationService
Documentation is quite vague and everything related to this subject mostly points towards AAD.
The requirement I have is to be able to show a video only to users who have a specific permission. This can be as simple as having a claim in their JWT. Using AAD isn't an option so I was wondering if there is any other way I can achieve this.
The way I could imagine this work is that you can specify a claim that you want Azure Media Services to check that the incoming JWT has and then specify the token's AES key or provide a certificate if you choose to go with RS token encryption.
It is NOT required to use any specific token provider (such as Azure AD). You can definitely create your own JWT provider (so-called STS, Secure Token Service), using asymmetric key encryption. In your STS, you can add custom claims as desired based on your business logic.
Make sure the issuer, audience and claims all match up exactly between what is in JWT and the ContentKeyPolicyRestriction used in ContentKeyPolicy in Azure Media Services.
I'm quite new to OpenIdConnect so excuse me if i still miss some basic concept.
I have a SPA-style web application I'm developing for my company (AspNet Core + Aurelia).
I want to use AzureAD via OpenIdConnect for authentication and authorization, everything works very well so far i'm able to obrain a token and sign in.
the problem is that my application needs to provide to the client's browser some app-specific claims like: can read X, can edit Y...
if i add these claims to the JWT token provided by AzureAD obviously it will became invalid, as the signature will not match the content.
if i generate a new token with the new claims, but signed with the app key, obviously it will be a different token valid only in the context of my app (what if I'll later need to access some other resource using the AzureAD token?, is it a good idea to insert the AzureID token as claim of the newly issued token?)
Are there something I'm missing in the OpenConnectId? or is there a way to add claims to a token issued by a 3rd-party provider like AzureAD while keeping the token valid? Maybe a way to ask AzureAd to add claims to the token and re-sign it?
I think a good way to solve this situation may be to obtain an access_token for my own application's api (from my app backend) in exchange of the id_token provided by azure (after its validation)
so the application frontend in the browser will own two tokens and it will be able to use the correct one for each type of request.
there are some standardized flow that are quite similar to this but not exactly the same.
You could try to use a custom claim mapping policy. This is documented here.
This feature is used by tenant admins to customize the claims emitted in tokens for a specific application in their tenant.
As far as I can understand, this is still in preview stage. So it may require some trial and error verification.
Alternatively, you can define some policy in your application itself. Given that you know client IDs from your application (hence you require to use them for OpenID Connect requests), you may create a simple policy to check tokens and perform verifications.
When you use Open ID connect with Azure AD, the JWT issued token (id token) is signed with an asymmetric key. I saw the public key to verify that signature is available in the metadata file, https://login.microsoftonline.com/common/discovery/keys. However, I couldn't find any documentation about how those keys are generated. How can you change the keys that are available there or how can I specify a different key to sign the JWTs for my tenant ?
All sources and information suggests that this certificate roll over is done by Azure AD them self. Consumers are not able to do a manual roll over or put a certificate of their preference. This claim is supported by this answer. Also, please check this press release which mention a roll over happened in 2016
From your end you must be be ready to accept a rollover any time. Best practice is to fetch key information through discovery document. This is explained in the openid connect documentation
According to this piece of documentation, only way how to have your own signing key for your application, is custom claims mapping. Although description is very vague and instructions how to do it are scarce.
I'm putting together a personal React site and want to send requests to an AWS API Gateway. However, I just want my site to be able to pull data. There will be no user model and every auth model I've ever used requires the user to do something with sign-in, be it user/pwd or AD. Can someone guide me to a model that covers this scenario?
One common approach is to use a Cognito Identity Pool with "Unauthenticated Identities" enabled. You can secure your API gateway endpoints using IAM, and require requests to be sig4 signed.
With this approach, Cognito is used only in a kind identity broker capacity, not as an actual identity provider. You do not need to create a User Pool or use any other identity management features of Cognito. In this capacity, Cognito is essentially just a thin layer between your code and the underlying STS APIs that produce the IAM keys your application needs.
Using the Cognito SDK, you request temporary IAM credentials (access key, secret key, session token) that can be used to sign the requests.
This answer outlines one way to accomplish this. When the protected AWS resource you want to access is API Gateway, your code may look something like the example near the end of this post.
I typically either use aws-api-gateway-client, as the example does, or aws4 with axios to sign requests.
As noted in the linked to answer above, I normally use AWS.config.credentials.get(), rather than AWS.CognitoIdentity.getCredentialsForIdentity() to actually get the IAM keys (as in this doc).
The signed requests then include an Authorization header that is very difficult to counterfeit. I don't want to suggest that this approach is bulletproof, but it does at least give you a reasonable level of confidence that your API Gateway endpoints are only being successfully invoked by your application.