I would like to customize the password policy for my B2C Custom Login Flow. I can see how to change things like password length etc (see Password Polices)
But I also want to prevent the user from using any of the last 8 passwords. How would I do this?
This capability is currently not supported in Azure AD B2C.
Here is the feedback, please go and upvote this.
The best you can do with built in functions is: https://github.com/azure-ad-b2c/samples/tree/master/policies/password-reset-not-last-password
For more than last password history, the only workaround is to store the hashes yourself and use a REST API to examine the hash against the new password being provided. Something that we dont recommend doing, and rather using better techniques such as MFA.
Related
Is there a way to use the generated random password while creating the account using Signup Custom policies?.
I understand that this is possible using Graph API but we are looking at the possibilities using the policies.
If you are referring to the password a user would use to login to their account, then no. As detailed here the only thing custom policies can do with user passwords is write them to the directory. You cannot read a user's password from custom policies (or from anywhere as far as I am aware).
I'm not sure which random password specifically is being referred to (if you are following an example, posting it may help), but you would have to store it elsewhere (which obviously carries security issues with it) and then retrieve it using an API of some sort during policy execution
Scenario:
I am working on a corporate site, on which you may log in, but it is not a forced requirement.
We have enabled the KeepMeSignedIn / Remember me functionality on the aadb2c login page, but i cannot seem to figure out how to notify my website, if a user has selected to KMSI.
My Question:
How can I signal back to my website, if the user has chosen to use the KMSI / Remember Me functionality on AADB2C.
I can't seem to find any information solving this challenge and I would very much appreciate your help and input.
Kr Ole
You can use the KMSI Claim Resolver to detect if the user selected KMSI check box and issue the claim into the token.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/claim-resolver-overview#context
I don't need Microsoft Login screen.
If I am already having username and password with me ,
can't I just pass them using Http client and get the authentication token.
Is it possible , please suggest.
The Azure AD supports various flow about OAuth 2.0. To acquire the access token with username and password directly, we can interact with resource owner password credential flow. However this scenario should be used carefully since it may leak the password. You can refer this flow about specification from rfc6749#page-37.
And to implement this flow using C#, you can refer this blog.
The short answer is, it is possible but not recommended (See comments from Philippe below).
The ability to get a token when you have a user name and password is extremely limited.
You might be able to do this in rare scenarios when your device is not able to prompt the AAD Auth page, or in cases when it is a native app/automation tests and etc.
Please see this post for the limitations and workarounds:
http://www.cloudidentity.com/blog/2014/07/08/using-adal-net-to-authenticate-users-via-usernamepassword/
Also look at this answer from me here, where I made it to work for our automation tests, but Vibronet has comments that, this solution will stop working, but not sure it has happened yet or not.
How to acquire a user based token from Azure Graph API
I am trying to research what options are available when using 3rd party authentication for a web application. I would like to have the ability to customize which information is submitted when a user authenticates as well as control the branding of the login.
I would also like to be able to manage how password recovery/reset is handled.
Any suggestions?
EDIT: I wanted to add more information to detail what I was looking for. Essentially and am wanting to hand off all the password reset, authentication, and management to a third party. Just like OpenID. However, I don't want to user/customer to have to go to an OpenID provider as I think it could be confusing. I would like them to enter a username and password on my site but be authenticated by another provider. Does that make sense?
If it's helpful still, I compared (5/18/2015):
Auth0
AuthRocket
UserApp
DailyCred
Conclusion for me was Auth0, because while all the features are very similar, it felt the most legitimate, as in it's not a start-up that might disappear in a few months. Now, the reason that was super important for me was because login is a foundational requirement, so I need to believe as a customer that the Authentication as a Service will be up for as long as I will be.
Here's the full comparison story:
https://medium.com/#bsemaj/authentication-as-a-service-comparison-5-quick-lessons-for-b2b-businesses-e7587275824c
EDIT: (summary): I'm looking first for a way to have a custom, user-specific attribute passed to us as part of the ADFS signon; if that's reasonable, I'll dig into how to secure it.
EDIT: (clarification): I don't want to pass something through AD at time of login -- if the user has to enter their password and then authenticate again against AD, they're going to end up with confusing, mis-matching passwords. Instead I want registration with us to go like this:
user enters details (email, etc)
we generate a long random string, encrypt it, then provide that as part of a unique id to the client's AD
Then at each login:
We redirect the user to the client's AD for auth
Once the user is authorized, they're redirected back to us with user & claim info
That info includes the unique ID we generated -- so we extract a user ID and decrypt the password from that.
This would be lower security than we normally offer, but it's the best I can imagine if AD is involved. Is this possible?
Long version: A customer is asking that we add support for single sign-on to our web application, implementing Microsoft ADFS (Active Directory Federated Services).
The problem is that we rely on the user's password to decrypt their record; their private key is encrypted with their password, so we can't access their record without the password.
I've been digging into the documentation, e.g., http://msdn.microsoft.com/en-us/library/bb897402.aspx -- but currently I don't see way to securely manage some kind of secret encryption key using AD FS.
It wouldn't have to be the password itself, of course -- we implemented OAuth2 by generating random access tokens that have the same properties as a password (can be used to decrypt the user's record)... but an incoming, authenticated user needs to come with some kind of secure, private token.
Any guidance much appreciated!
If you are using ADFS 2.0, you can customize the pages.
So you could e.g. take the password, mangle it, write it to AD before invoking the SignIn and then have a claims rule that passes this. Then reverse the process in your application.
Note - I'm not suggesting that this is a "good" solution - just an example of what you can do.
Obviously security needs to be paramount!
Well there is Two ways to get your problem solved.
Customize the ADFS SignOn page(you should anyways take a backup) to create a form that receives users password. It is an webforms aspx page so you should have no trouble doing it. From there you must build your own STS to issue claims to ADFS so that ADFS can in turn pass these to your relying party. Map the custom STS as attribute store to the ADFS
You are just doing things wrong by taking security in your hand. ADFS uses HTTPS for transport level security and secure encryption with SAML 2.0 to handle your information, so another encryption would be no-brainer.
let me know which way you like going