I'm running FreeIPA 4.6.6 on Centos 7. However I only want to enforce 2FA (password + OTP) for members of a specific ldap group? Is that possible?
No, 2FA handling in FreeIPA does not work this way. The enforcement is done either globally or defined per-user. There is no group-based policy that would enforce 2FA requirement for a user. It also depends on whether user already has a token or not.
If you can describe a use case for group-based enforcement, please file a ticket at https://pagure.io/freeipa/new_issue. It would be good to understand what are practical needs here.
Related
I am using forgot password to change my GitHub password, but it's required 2FA credentials and I lost the 2FA app as well. So is there any I can change my password without using 2FA credentials?
A list of possibilities is given in this help page on GitHub.
To summarize, you can recover your account on your own, even after losing your 2FA app, if you (already) have:
A recovery code: you can download and safely keep a list of backup codes for situations like this.
A fallback number: a second phone number associated with your account.
A security key: you can have, for example, a physical USB stick as a security key.
Without this, there are two more methods provided, but will take longer and are not guaranteed to recover your account:
Using a verified device, SSH token, or personal access token: you can apply for account recovery by proving that you are logging in from a device you have used before, or using a SSH or personal access token that has been used before. The request will be then manually considered by GitHub support.
Using an account recovery token on Facebook (if you have set it previously): This also requires manual verification.
In general, to avoid such issues in the future, it would be advisable to download (and perhaps print a physical copy) of recovery codes for each service you use 2FA with, as that would be one of the easiest and fastest ways to recover your account.
I am currently developing a RESTful API server, and I am choosing between using ID and password or using a token to authenticate a user.
Let me, explain my situation first. I need to include static authentication information to my library to communicate between a client and my server or provide it to a partnership company to communicate between their server and my server. And when I was researching other services which are in a similar situation as us, they are using token now (for example, Bugfender is using a token to specify a user).
However, what I think is that using ID and PW and using the token are the same or using ID and PW is better because there are two factors to compare it is correct or incorrect.
Is there any reason why other services are using a token?
Which one is better as a security perspective or is there a better way to do this?
I think, if you are going go use on your client fixed username/password, or some fixed token, then the level of the security is the same.
Username and password is not considered as multi-factor authentication. Multi factor means that you are authenticating someone by more than one of the factors:
What you know. This can be the combination of username and password, or some special token.
What you have. Might be some hardware that generates an additional one time password - Google authenticator app on your telephone, or SMS with OTP received with some time expiration.
What you are. This is for example your fingerprint or retina of the eye.
Where you are. This can be the IP address of the origin if it is applicable for your setup.
How you behave. What is your normal way of using the service.
etc.
Maybe not needed to mention that both - the token and the username/password combination have to be carried in an encrypted requests (I believe you are using HTTPS). Otherwise the client's identity can be stolen.
How are you going to provide the credentials to your client library? I thnk this is the most tricky part. If those credentials are saved as a configuration (or worse hard coded) on their server, is that storage secure enough? Who is going to have access to it. Can you avoid it?
What would happen if your partner company realize that the username/password is compromised? Can they change it easily themselves? Or how fast you can revoke the permissions of stolen credentials?
My advice is also to keep audit logs on your server, recording the activity of the client requests. Remember also the GDPR if you work with Europe servers, check for similar regulations in your country based on what you are going to audit log.
In case the credentials (ID and password) and the token are being transferred the same way (say: by a header in a REST request) over a TLS secured channel, the only difference lies in the entropy of the password VS entropy of the token. Since it is something for you to decide in both cases, there is no real difference from the security perspective.
NOTE: I don't count the ID as a secret, as it usually is something far easier to guess than a secret should be.
I'd go for a solution that is easier to implement and manage.
IMHO this would be HTTP basic authentication, as you usually get full support from your framework/web server with little danger of making security mistakes in authentication logic. You know, friends don't let friends write their own auth. ;)
I have a multitenant aad app for which token validation needs to be done. I have access to the token in 'TokenValidated' event handler. For now, I have the property 'ValidateIssuer' set to true. Looking online, I noticed a lot of places this property is set to false for multitenant applications and there is a mention of custom validation. Can someone tell me what extra token validation needs to be done for multitenant applications? Examples will be helpful.
I have read about ValidatingIssuerNameRegistry, but don't know if that applies in my scenario since we do not restrict any specific tenants.
Thanks
-Ravi
Here's a great article on token validation you may find helpful. The Azure AD Token Claims Article is also extremely useful.
Issuer validation is used to indicate the sts that issued the token and the tenant for which it was issued. So in the case of a multi-tenant app, you may choose to turn off issuer validation as to not limit any tenants from signing in. In the single tenant or n tenant case, you can use this to only allow tokens from specific tenants.
The other validation necessary is signature validation. Doing this ensures the token was actually minted from Azure AD (issuing authority) and not fabricated from some nefarious source.
We are a service provider. Suppose in our application, we originally have our own user/role management. Different users with different roles are allowed to use different features. So that when a user login we need to know which roles this user has, and prepare appropriate UI. We have administrator role, users with this role can assign roles to other users.
We are thinking of enabling SAML SSO for our application, now the problem is how do we setup roles for each user.
Solution 1, we relies on IdP to provide role information for each login user, the role information may come along with Assertion, but this may not work for all the IdPs.
Solution 2, we only retrieve user from the IdP, and manage the roles in our own application. For example, when we get an Assertion, we retrieve the username(or email address), and match with a record in our DB, if it doesn't exist we automatically create one for this new user. Then we rely on users with administrator role to assign correct role for this new user.
Now the questions is where is the first administrator coming from? Our customer gets our application, and turns on SAML SSO, now there is no users in the DB yet, then how can we resolve such bootstrapping issue? Is there any kinds of standard way? We have come up with different options but not sure which is better and what are the concerns for each options.
Option 1, have a default built-in administrator user. There is a regular native login page that built-in users can login without going through IdP(there is an option to turn it on/off if SAML SSO is enabled)
Option 2, during SAML SSO setup, ask for the administrator user name, so that we automatically create this user in our DB with administrator role. Then when this user login through IdP we could match him in our DB.
What are the other options?
For your first question about who should handle the roles. As I understand every customer has your One of your service provider software. And it connects to a central IDP that you own. If this is the case, it feels like its to complex letting the administrators handle roles on your IDP. I would go for number two.
About question number two. I have been in the same situation I can not remember that I have seen a obvious standard solution for this.
What we did was option 2. It works fine but it adds some complexity to the install procedure. We choose it because we would not have a native login page.
I thing maybe I would be better to go with option 1.
You can get the roles from the different directories of your IDP using your authorization layer. It removes the constraints on SAML and gives the same results as your solution 1.
I have a question regarding ADFS and forms authentication. I currently maintain a database of users and have built a somewhat complex claims-based system around it. All of my clients use forms authentication to access my website (ASP.NET). Recently one of my clients expressed a desire to switch to a single sign on model. I would like to use ADFS to accomplish this. My question is how do I go about using both forms authentication and ADFS at the same time. I need all of my other clients to still be able to access the site using forms authentication. I know this cannot be a rare problem, but I can't seem to find any good answers to the question. Thanks very much.
using ADFS V2.0 allows both types of authentication, windows and forms and both relies on the active directory that means you must save and keep all the users data in the active directory.
pleases see http://www.richardawilson.com/2010/10/adfs-20-login-page.html
if you need the ADFS reads the users and credentials from another source than the Active directory,
in that case you must implement a custom claim provider and configure the ADFS.
Not sure I totally understand the question but ADFS can use FBA - AD FS 2.0: How to Change the Local Authentication Type.
Is your "complex claims-based system" a STS? If it is, just federate with ADFS.
If it isn't, have a look at Thinktecture IdentityServer.