How do I use Azure B2C with Entity Framework, or any other back-end system?
The documentation for Azure B2C does not seem to discuss integration with back-end systems, and I'm at a loss as to how this is achieved.
I do not need the user to authenticate against the database, but I want to store user-specific data in the database. This could entail the use of a Users table, for example.
The design of the DB is up to you.
The normal way is to add the DB primary key of the user as an extension attribute for the user in B2C.
When the user logs in, get the extension attribute and pass it to an API that handles all the DB activity.
See MS documentation Use API connectors to customize and extend sign-up user flows and custom policies with external identity data sources
you can verify that the email address provided by the user exists in
your customer's database, and if not, present an error.
Your RESTful service can receive the user's email address, query the
customer's database, and return the user's loyalty number to Azure AD
B2C
You can use an example
A B2C IEF Custom Policy which authenticates to AAD and calls a REST API for more claims
Related
I also need to add the created/updated user into a users-table of an RDS-database, and the described workflow does not describe such a scenario at all.
Is it possible to react to the create/update of a cognito user within this SAML-workflow, by also updating an applications database-table with the new data?
--
In the docs of AWS Cognito in the Chapter "SAML user pool IdP authentication flow" there is following part written:
6. After verifying the SAML assertion and collecting the user attributes (claims) from the assertion,
Amazon Cognito internally creates or updates the user's profile in the user pool.
Amazon Cognito returns OIDC tokens to the app for the now signed-in user.
see: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-saml-idp-authentication.html
this part does not seem to recognize the scenario i described in my question, and there is no link/hint to such a solution given.
In order to perform additional actions to customize the Cognito user pool workflow, you can use Lambda triggers.
In your particular situation, there are triggers and triggerSource values you should look for regarding Sign Up and Sign In for federated users, as per documentation, namely:
For SignUp:
PreSignUp_ExternalProvider this is called before the user is created in Cognito, allowing to perform some additional actions, normally validations.
PostConfirmation_ConfirmSignUp is invoked after the user has been created and confirmed in Cognito. This would be where you'd create it at the RDS Database.
For SignIn:
PreAuthentication_Authentication similarly to PreSignUp, useful for additional validations, but for Sign In.
PostAuthentication_Authentication called after a successful authentication. This is where you would update the User at your Database.
Also keep in mind that the Updated date of the user will change at each new sign-in due to this (source) :
Amazon Cognito must be able to update your mapped user pool attributes when users sign in to your application. When a user signs in through an IdP, Amazon Cognito updates the mapped attributes with the latest information from the IdP. Amazon Cognito updates each mapped attribute, even if its current value already matches the latest information.
I am in the process of expanding our login options on our product to support MS Identity Platform, to be able to use Azure AD login (and gain SSO/MFA with that)
Currently we are using .Net Core + JWT (JwtBearerDefaults.AuthenticationScheme)
The environment is angular clients, .Net Core APA, and a back-end database.
I have the setup working.
My challenge is that in our business model and backend database we have ~2.000 userrights and our own User/Role model granting access.
I am currently getting the IdToken from MSAL and in my proof of concept using the oid to couple the Azure ID with our User model.
But, in our existing JWT solution, our access token holds claims about the User Id, but also the role, and another property (Unit/Vessel) determining access. From these three properties we can verify against the 2.000 userights on API side whether or not a request is allowed or not.
I would like to keep this information (User, Role, Unit) in the token - but have doubts on how.
Constraints:
We cant create/use Azure claims. We have too many, and customers will manage the Azure application - while we create, add, remove rights for each version of our software.
Azure don't know about role/unit data - and these are different for each customer - so that information can't be in Azure either.
My best idea is outlined below - would this approach be correct, and live up to the way ID/Access is separated?
I hope someone can give me some feedback on this.
My idea is, that the Angular client gets the Azure IDToken. I then use the Azure IDToken, call our API, which on server side, validates ID Token, and then grants me an access token, which contains the user, role and unit. This token is not Azure'd at all, just a token generated by our API - which again will be the only one validating it). Pro's on this approach is also I can keep one type of Access Token, no matter which IDToken is supplied by Azure or our own API.
Tried to outline the flow below in this DrawIO diagram.
I hope someone with more experience in the Token field can validate if this would be a viable approach?
Best regards
/Anders
This is a viable approach except for one thing.
Do not use Id token for authorization.
Your front-end should acquire an access token from AAD for your back-end.
This access token contains the user objectId, allowing you to map the user to a user in your database.
An Id token is only meant for the application that requested authentication and tells it metadata on the user like their display name etc., but it is not meant for authorizing anything.
I have an Azure AD Tenant that is federated with ADFS.
ADFS has an attribute called "employeeNumber".
When a user authenticates against AAD for accessing our custom Web API, i would like the jwt provided by AAD to contain the claim "employeeNumber".
Once the user is authenticated against the custom Web API, the code must check the presence of this claim and its related value.
I've found some tutorials for doing something like this but they refers to SaaS applications.
Attribute sync tutorial
Custom applications registered in AAD don't have the option "provisioning" that the above link refers to.
Thank you.
Are you using AAD Connect?
That needs to be configured to pass the attribute.
Then you need to tell Azure AD to pass the attribute by modifying the manifest.
I am designing a simple REST API with Stormpath Facebook integration and wondering what would be the best pattern for user authentication. Currently I do not have any endpoint for user creation, so all requests to my endpoints are authenticated like this:
Get Stormpath Application object based on API_ID and API_SECRET configured in my app
Get Stormpath Account object based on Facebook token specified in every request
Based on account status authenticate request or reject
This follows more or less official guide and works fine because even though user account does not exist it will be created upon first get account request to Stormpath. Does it make sense and is it safe enough? I was looking for some documentation or best practices but could not find anything.
I would also need to get / generate unique user ID so I can make some relations with user data in my system - so another question, what is the best approach here:
Generate some unique ID, associate it with user email got from Stormpath and save in my system - I think this violates a little bit idea of such a service like Stormapth which encapsulates all user data
Do the same as above but store it in Stormpath Account customData
Use Stormapth user resource ID which can be obtained from user URI
Please advice.
Just for the record I am using Stormpath Java SDK and designing the API to be a backend for mobile social app so security is quite important for me.
Full disclosure, I manage Product # Stormpath. I'll be using your feedback to enhance the documentation.
It is hard to say if it is safe or not, without understanding the REST API you are building. If you made a REST API for cat pictures, my answer would be different compared to medical / financial information. One way to look at it, is that Facebook has the Graph API (REST) and they protect access requiring the same access token you are using. There are other flags that would cause me to say it isn't safe, like if you were using HTTP with no TLS.
To your second question, how to link Stormpath with your data. I wouldn't say you would violate anything about Stormpath by modeling out your application that makes sense to you and your app. Stormpath has customers that store EVERYTHING about their users in Stormpath. Stormpath also has customers that use Stormpath solely for authentication and authorization data and use customData to draw the link between a Stormpath user account and their data.
How / where you store the information is based on your needs. If you are starting with authenticating the user account with Stormpath, it would make sense to put the unique identifier / primary key in the user account's customData. If you are starting with querying your data store for the user data and need to get the Stormpath user account, then you will need to store the href for the user account in your data store.
A nice feature in the Stormpath SDK for Java is that when you do authenticate with Facebook, the returned object will disclose if the account was newly created or if Stormpath has existing account for the access token:
https://docs.stormpath.com/java/apidocs/com/stormpath/sdk/provider/ProviderAccountResult.html
This means that you will know when you need to create a record for the account in your data store and connect the two using customData and/or the user account href.
What are best practices for maintaining roles (e.g., a user-provisioning role) in a Web application that uses OAuth 2.0 authentication against a Google App domain? These are roles that are tied to a specific Web application, rather than to the domain as a whole.
Is role management at the application level typically done using the application's backend database, once the OAuth Web flow authorization has been completed? I was thinking of using a Google App group to stand in for each role and then verify membership in the group using the Directory API before allowing an action to be carried out. Is this a suitable approach? This requires either a service account with a group-membership privilege or the assigning of such a privilege to each user in the domain with that role, which are steps that would be nice to avoid.
Is there an API to read information about Google App's native domain-level roles for this? Should custom properties on the user's profile be used? If the latter, is there a straightforward way for a domain admin to set these up when provisioning a new user in the domain, or will a separate UI need to be built out? I've noticed that in the user profile information there is a isDelegatedAdmin field, but that field is a boolean, and I have not found anything with more granular information on the roles delegated to the user account.