We are using AWS Cognito (Federated Identities) in order to provide login via facebook and google+.
We are facing the following challenge. Our company is providing different apps, that interact with each other, so that we would like to have authenticated users to have one identity inside of one cognito identity pool. And to make use of the sync store cross apps.
For cognito you can only choose one audience (client-id/app-id) for each IdP, when using the AWS console. It would make sense for us, to associate many facebook audiences and google+ audiences with that one cognito setup.
We figured out how to setup many google+ audiences, by creating google+ as IdP via IAM. Which works perfectly fine for us.
We are struggling to figure out a way how to configure many facebook audience via IAM-IdP or any other way.
Well, facebook is no open-id-connect provider, and that seems to be the issue. But I kind of don't want to accept this.
Does one of you know how to configure multiple facebook apps to be associated with one cognito identity pool. Workaround are very welcome.
One additional information: It would be OK for us to use one global facebook app, e.g. 'OurCompany - Network', that would do the trick. The blocker for this is, that it would block us from doing facebook-campaigns with installation tracking. If you know a workaround for this, is also a welcome solution.
I did this by using multiple pools, and then allowing both pools at the role level. That means my Trust Relationships for that role look like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "cognito-identity.amazonaws.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"ForAnyValue:StringEquals": {
"cognito-identity.amazonaws.com:aud": [
"<first cognito pool>",
"<second cognito pool>"
]
},
"ForAnyValue:StringLike": {
"cognito-identity.amazonaws.com:amr": "authenticated"
}
}
}
]
}
One workaround is to use Developer Authenticated Identities. You will need to validate the Facebook token yourself in this case.
Related
I'm trying to make a POST request to our KeyCloak.
I can create a user with no problem but once i provide the post request with the federationLink this isn't picked up. I tried it both with the ID and the string of the Federation Link. I noticed that the added Attributed aren't picked up aswell.
The body i post is:
"username": "xx#local",
"email": "xx#local",
"emailVerified": true,
"enabled": true,
"federationLink": "qa.exn-dir.xxx.com/cn=xxx,cn=xxxx,o=xxx",
"attributes":{
"PHONE_NUMBER": [
"xxxx"
],
"CARD_NUMBER":[
"xxx"
]
},
"credentials": [
{
"type": "password",
"value": "12345"
}
]
And i post this to /auth/admin/realms/REALM/users
When looking at the created user this is still in the default federation and not the one we provided in the body.
Any idea how i could solve this?
User federation in keycloak provide functionality to import user data from your selected LDAP system, source from keycloak documentation
Keycloak can store and manage users. Often, companies already have LDAP or Active Directory services that store user and credential information. You can point Keycloak to validate credentials from those external stores and pull in identity information.
That means keycloak does not store the user credential, keycloak only point to those external stores to validate the user credentials.
Quoting from your comment replying to #sventorben
Thanks for the reply. The users that we need to create in case are external users and they need to be added in keycloak using the API. Atleast that is what i'm told.. But they need to be added to a specific federationLink. This is my first time using KeyCloak so i'm still new to the whole thing
In case of your requirement to create external users:
You can create it and store the user data information and credential in keycloak, that means you need to send the appropriate user data and credentials along to the keycloak so that keycloak can use it.
Or if you prefer to load the users data and validate the credential from your LDAP system, then first you need to register the external users to your LDAP system just like #sventorben said, and then let keycloak automatically synchronize these new users (based on your synchronize settings of the user federation) or if you prefer manually, you can do it via keycloak admin console.
Use-case:
We have a few AWSGateway APIs which our clients can use to do somethings in the backend. These APIs are Cognito protected. Currently our clients are using this APIS through an android app which was built using Cognito Mobile SDKs.
Now we are trying to expose these APIs to our clients to be integrated into their internal workflows.
I was trying to find what is the best way to do this. Currently I am not able to find any resources on how to do this.
I have seem the server side user of AWS Cognito but I don't think that is what we want to do here.
Thanks.
To answer your question correctly we need more information.
Can the internal workflows be configured to use REST Services?
What authentication processes does the internal workflows support?
SDK or no SDK
You can access the webservices in API Gateway via a generated SDK or your own code.
Instructions to generate an SDK from the API Gateway Console are found here.
To invoke the webservice with authentication can be done in four ways IAM, API Keys, Cognito, custom authoriser. I am going to mention the first three.
IAM
Step 1, create a user in IAM with an access key and secret key.
Step 2, is too setup a role to access the API using IAM. Go to
IAM, select roles, create a role, and grant it access to your
API Gateway functions. Which would look something like this:
Sample IAM Policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::account-id:user/Alice",
"account-id"
]
},
"Action": "execute-api:Invoke",
"Resource": [
"arn:aws:execute-api:region:account-id:api-id/stage/GET/pets"
]
}
]
}
allocate this role to the user you created. Policy examples are available here.. For more authentication options that include local certificates etc look here.
Step 3, call the API using the AWS Secret and Key SDK.
API Keys
If you add keys to your APIs the mobile app will fail as it does not have these keys. It would be best to deploy a different version of your APIs that could wrap the existing ones, could provide additional functionality specific to the workflow. To find out how to do this follow this link.
The advantage of API keys are that you can throttle access to your API Gateway functions, remove the keys at will, recycle them etc.
Cognito - Federated Users
Your mobile users are actually authenticating using federated users. However, one of the federated user channels happens to be cognito. You can add more, OpenAuth, Google, Facebook, SAML, etc, here you could add the Authentication type used by your client. A user would then use their username and password, to authenticate to the clients security provider, those credentials are then passed through to the API via federated users, and therefore federated users must be setup to use the same authentication mechanism as your client. See the following blog post
For this solution we have multiple options. 1. Pass the user credentials through to the API with federated users, this assumes the users interface calls the webservice but as you mentioned it is workflow, and I assume the user does not access the service directly as they do with the mobile application. i.e. services are called by a machine as a background process on a server. Which means this solution will not work. Option 2. is to create a new user, in cognito for the client. This is the same as accessing the service via the mobile app. To do this needs a little work extra work on the client as you need to retrieve the temporary access tokens.
Step 1. Use the SDK, or code the interface to the API on your own.
Step 2. Generate a user in Cognito for the backend system to use.
Step 3. Use the cognito user to obtain access tokens
Step 4. Use the access tokens to access the webservice in API
gateway.
Suggested solution
Create a second version of your API as a wrapper or extension to your mobile API and use API Keys as described above. Why?
Can throttle access to the APIs
A different version means you can extend it and add additional functionality specific to workflow
Easiest to implement as there is no key exchange, such updates to
the request header.
EDIT: My suggestion of solution 2 is incorrect. AWS Documentation says the following To include API methods in a usage plan, you must configure individual API methods to require an API key. For user authentication and authorization, don't use API keys. Use an IAM role, a Lambda authorizer, or an Amazon Cognito user pool.
AWS Also says the following is available for controlled access
Resource policies let you create resource-based policies to allow or deny access to your APIs and methods from specified source IP
addresses or VPC endpoints.
Standard AWS IAM roles and policies offer flexible and robust access controls that can be applied to an entire API or individual
methods.
Cross-origin resource sharing (CORS) lets you control how your API responds to cross-domain resource requests.
Lambda authorizers are Lambda functions that control access to your API methods using bearer token authentication as well as
information described by headers, paths, query strings, stage
variables, or context variables request parameters.
Amazon Cognito user pools let you create customizable authentication and authorization solutions.
Client-side SSL certificates can be used to verify that HTTP requests to your backend system are from API Gateway.
Usage plans let you provide API keys to your customers — and then track and limit usage of your API stages and methods for each API
key.
Not all the approaches above are intended for authorisation, for example CORS actually protects the user from cross site scripting, and as seen API Keys are only for usage plans. Resource policies just further secure the API by limiting access to IP Addresses, thus your only options really are IAM Roles as described in option 1, and federated users as described in option 3 or your own custom lambda authorize, if you are using Lambda, or your own authorizer if you are using something other than lambda wrapped with API Gateway.
I guess it will be service to service or (Server to Server) communication, for this terminology used is Oauth Standard is client_credentials grant type.
Please refer the documentation for getting token
Once the token is acquired, you need to pass this token either Authorization or API Gateway Custom Header for AWS Cognito.
You can use API Tokens alone for authorization (unless this has been removed recently)
I have used them on multiple applications.
This is not recommended for Authentication -- but it is application specific if they are sufficient for authorization
They have been supplemented by more secure methods at the expense of significant complication for both client and server.
API Tokens have the advantage of ease of use for issuer, client and server as they do not require complex signing or protocols -- however they are not as fundamentally secure as they may be reused and generally do not expire as quickly. Otherwise they are equivalent to bearer tokens.
Security is very context dependant -- consider these question:
what exactly are you protecting against (providing security for) ? What is the risk and cost of a security breach ? What is the cost/effort to implement and use it?
Many security 'holes' are not in the authentication protocol handling itself but rather in how data is managed 'outside the box' -- No security is perfect, meaning aiming for perfect security has unbounded cost with decreasing effectiveness. Generally, it is recommended to balance the risk and cost of potential loss vs cost to implement and maintain.
You can have a 'highly secure' API but also have a high risk of breach and data loss due to handling before and after passing through the protected gateway. There are many reasonable cases where instead of focusing on securing the 'front door' with bank vaults and armoured trucks, instead securing the data handling such that no data that is a significant security risk passes through the front door.
AWS Provides a range of technical features -- but it is ultimately up to each customer to implement them appropriate for their use. API Keys do have a range of appropriate use cases, particularly in server-to-server communications, especially where personal identity (and PI data) is not involved, or where the API involves mainly services instead of data (e.g say a image thumbnail API that stores no state and provides no access to data). When backed by use of HTTPS/SSL and possibly other security factors such as account passphrases, IP range whitelists, and a general policy of least-access.
Don't underestimate the "Sticky Note" factor. If you make secure access too painful to your users they will find a way to make it less painful, but less secure then simpler measures which they would not have had an incentive to circumvent.
We are evaluating VSTS for an enterprise use.
One of the challenges from security team is lack of control and governance around usage of PAT (personal access tokens)
As I understand, any user can create one or more PAT and this PAT could be used from outside network to make REST API calls (or to connect with tools outside network) to VSTS to access information.
Have number of questions around this scenario and any insights/ workarounds from your experience are appreciated
How is your organization handling this issue or has worked around this issue? Looking for options to get buy-in from security team. Has anyone ever approached Microsoft with this problem statement? I am sure there are many enterprise customers, wondering how did they tackle this issue.
Is there a way to disable creation of PAT for all users? Don't see any option, but any workaround to enforce this.
Is there a way to get list of all PATs across all users? Don't see any option in VSTS, but may be through a script of some sort
Thanks
Update
There is now an API to list which PATs have been created and the option for an admin to revoke PATs on behalf of their users:
GET https://vssps.dev.azure.com/{organization}/_apis/tokenadmin/personalaccesstokens/{subjectDescriptor}?api-version=5.0-preview.1
Response:
{
"value": [
{
"clientId": "00000000-0000-0000-0000-000000000000",
"accessId": "00000000-0000-0000-0000-000000000000",
"authorizationId": "952858d3-7084-4635-964e-3c2a57645185",
"hostAuthorizationId": "00000000-0000-0000-0000-000000000000",
"userId": "bb5bb6c8-ef0a-400f-8987-92b3674d2043",
"validFrom": "2018-07-19T00:00:00",
"validTo": "2018-07-19T00:00:00",
"displayName": null,
"scope": "app_token",
"targetAccounts": null,
"token": null,
"alternateToken": null,
"isValid": true,
"isPublic": false,
"publicData": null,
"source": null
},
....
More details here:
https://learn.microsoft.com/en-us/rest/api/azure/devops/tokenadmin/personal%20access%20tokens/list?view=azure-devops-rest-5.0
And to revoke tokens of other users then use:
POST https://vssps.dev.azure.com/{organization}/_apis/tokenadmin/revocations?api-version=5.0-preview.1
[
{
"authorizationId": "532c7fe6-74f8-408b-8051-4abb73dca491"
}
]
See:
https://learn.microsoft.com/en-us/rest/api/azure/devops/tokenadmin/revocations/revoke%20authorizations?view=azure-devops-rest-5.0
There is an option to turn off Basic Credentials/Alternate authentication and SSH credentials, which are less secure than personal access tokens. There is no option to turn off Personal Access Tokens. I suppose the primary reason for this is that Git and the VSTS Agent infrastructure rely on these access tokens to work.
Since the Personal Access Tokens can be restricted in their scope, they're actually more secure than caching the user's credentials directly. They can also never give more permissions than the user already has.
You can't query all personal access tokens for all users, that would be a huge security violation. Exactly for the reason you're trying to restrict access to these tokens.
You can disable OAuth and Basic Credentials. This will not block Personal Access Tokens:
https://learn.microsoft.com/en-us/vsts/accounts/change-application-access-policies-vs?view=vsts
Impact on Azure Conditional Access is explained here:
https://learn.microsoft.com/en-us/vsts/accounts/manage-conditional-access?view=vsts
Important
VSTS only enforces conditional access policies when a user signs into services with their AAD credentials. Accessing VSTS using personal access tokens (PATs), alternate authentication, OAuth, and SSH keys circumvents conditional access policies.
Remember that when a person performs authentication using Azure Conditional Access and then leaves the building will be able to use that credential until it expires. In the end, security comes from education and monitoring, not from trying to put everything in an airtight container.
VSTS does keep an activity log which includes which users have performed which actions. This log will include the user's IP address. This way you can at least monitor the actions.
I apologize if this has been answered, but I have been searching for hours, and still don't quite understand. This is a specific question, and not a "which is best" question.
Specific questions are in italic.
I have created a RESTful API, which was at first meant to be completely open. However, the organization has now decided to create a first-party mobile app to consume and (to some degree) update the data.
I am investigating authentication frameworks (oAuth2), and was not sure if oAuth2 was the correct way to go to meet our goals. And, if it is, which Authorization Grants applied to which set of users.
Our goals are:
To allow users to login and create accounts in the first-party app, entirely through oAuth 2 providers (twitter, facebook, google). These users would have access to the greatest set of data via the first-party app.
Assign different roles to the users (admin, moderator, etc).
Allow other applications to register, receive token credentials, and have limited write access or expanded access to the data. This would open them for creating third-party apps or research systems.
Finally, we would like to keep some of the data completely open, with no authentication needed.
So, am I right in assuming that we want to setup an oAuth2 *Server* (Authorization and Resource Server)?
If so, which Authorization Grants apply to the above situations?
One last question: For users using the first party app, would the app be responsible for logging them in and keeping their access credentials? The API server serves NO html, and is 100% RESTful. Does it need to serve login forms?
If you need to both authenticate and authorize users to your API based on various OAuth2 social logins, you do need some kind of API server or service where you can define your users and groups/role and the scopes that are available to users based on your rules.
Some cloud-hosted options for this are:
Auth0
Firebase
If you integrate with a service such as the ones above, you can let the service take care of authenticating users and just make sure that every user call checks against the service first for permission before it goes ahead and does anything.
I don't understand why my User Pool will not Authenticate a method in my API.
I've started with the simple petstore example, and added an Authorizer for my user pool. The test button shows that the JWT I have is working. I applied that Authorizer to the POST method on /pets, added Authorization as a request header.
When POST to /pets with postman (or curl), passing the Authorization: Bearer <token> header I always get the response {"message":"Unauthorized"}
I've messed around with creating an Identity pool linked to the User pool, with an Authenticated role that has a policy allowing access to the API Gateway. I've created a group in the User Pool to assign this group.
There's got to be some piece I'm missing. All I want to to allow access to the POST method to any user that presents a valid ID JWT from Cognito.
The policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke"
],
"Resource": "arn:aws:execute-api:us-east-1:*:XXX/*/POST/*"
}
]
}
Which works fine in the simulator. I'm not 100% sure the policy should even be in play though. I'm not clear on how the provided User Pool authenticator would acquire the policy, it wasn't in any docs I saw. I just started throwing darts at the wall.
Would just like to hear that anyone has secured an API Gateway endpoint with a Userpool.
For me works without "Bearer" in the Authorization's header using Postman.