I am in the process of scoping out whats involved in setting up single sign on using SAML and ADFS. A query has come back that I can't answer and can't seem to find anywhere.
Is it possible to carry out the usual user profile actions via ADFS? For example :
Can I register new users via ADFS?
Can I provide forgotten password / reset password functionality via ADFS?
I'm getting confused and have a feeling I am barking up the wrong tree!
No, AD FS only delivers security tokens for Active Directory accounts, after providing some form of credentials for such an account. It does not make any kind of changes in Active Directory, nor anywhere else.
No, AD FS has no 'reset password' functionality. However, the AD FS sign-in pages can be customized, and the functionality to change the (AD) password can be added by customizing/creating the appropriate ASP.NET pages. Been there, done that. Unfortunately I cannot share that code.
(This answer applies to AD FS 2.0 only; I'm not sure about AD FS 1.0.)
#Marnix is correct - ADFS is an "Access Manager" not an "Identity Manager".
As you can customise pages, there is nothing stopping you creating provisioning pages or adding links to a provisioning system.
Word to the wise: The "standard" ASP.NET membership pages provision to a SQL DB which won't help you. ADFS authenticates against AD only. You need to use AD membership.
Also, for internal users who login to their desktop with WIA and SSO behind the scenes with ADFS, you get the standard password functionality e.g. password about to expire, change password etc.
In addition to that: Microsoft has another product which integrates with ADFS (and other auth mechanisms) called Forefront Identity Manager which provides password reset / user self management as well as account creation via delegated fine granted rights. All that using a web-interface.
i guess that is what you're looking for.
However: adfs itself is only a tool to provide federation and SSO - so it's there for authentication / delegation, not mangement.
Related
We're using Keycloak 12 for authentication in our portal and there are two different types of users:
Internal users (read from our internal LDAP)
External users (stored in Keycloak but without being synced with the LDAP)
We'd now like to use the "Forget Password" feature provided by Keycloak. After having configured the feature and the mail server, this works fine out-of-the-box.
However we'd like to restrict the "Forget Password" feature to all users which belong to (2), i.e. the internal users. These users are not allowed updating their password via Keycloak as this is done by another mechanism.
I couldn't find any information in the documentation so far if this is possible at all?
The Keycloak Forgot Password feature is applied at the Realm level, hence applied to all the users belonging to the Realm. For Keycloak, the LDAP is just an external storage with users to authenticate against. Consequently, out of the box, there is no way (as far as I know) for the Forgot Password to only be enabled to certain users within the Realm.
Even if it would be possible IMO it would not be a very user-friendly feature, since when one activates such a feature a new link will be shown to the users on the login page in case they have forgotten their passwords. So if a user from the LDAP would click on it, it would display an error or something?!
Alternatively, you can configure the LDAP of the so-called internal users in another Realm than the one with the Forgot Password enabled. And then configure the newly created realm to be an external Identity Provider, which the users could explicitly authenticate against it. So in practice, the users would lend in the normal login page, the external users could login normally, and would have the Forgot Password option enabled. The internal users would explicitly click on the external IDP to authenticate themselves. Log in using the external IDP would be a similar user-experience as log in to the normal login page, however, the Forgot Password option would not be shown.
You can see an example such configuration here.
I have come across a number of articles that discuss a similar matter but I cannot find a definitive answer.
My company would like to begin using Identity Server 3, however one of the requirements is to be able to authenticate an external user without them having to manually enter their credentials.
This must be capable of providing single sign on capabilities also as we have 3 different systems and our users should only have to sign in once.
Essentially, the external user has their own CRM.
The CRM holds their username and password for our software.
They then click a button in their CRM to launch our application
This redirects them to our website with a payload containing their credentials
We call a web service to authenticate the user
It is fundamental that we do not change this process for our partners.
Can I implement a custom service provider to provide the authentication or is there some other way of achieving this? If so, could you point me in the right direction for how this can be done?
Many thanks
Craig
I would assume that you'd create a mechanism for their CRM to get a token at the time the client logs into their site and then have them send that token via url to your callback page. This would use the machine-to-machine type grant, or the client-credentials flow. Then that page could validate the token and log the user in. There would have to be some sort of unique identifier between the two systems like email or something. Just an idea.
I'd like to know if its worth investing time into developing an IdentityServer3 implementation that would work similarly to how Sharepoint allows for an initial Login using Integrated Windows Authentication, but then allow user to login as a different user with a prompt for credentials. Our hospital has many users where their primary workstation is set up as generic login. I'd like to use integrated Authentication, but allow these users on generic workstations to re-login as themselves.
From my research I think a logout page that actually invalidates the original token along with a secondary external Identity provider running without integrated Authentication is where I'm heading, but would like some validation that its feasible.
You would approach that problem differently with IdentityServer - on the login page you would give the user a choice. Either use integrated authentication or specify some username/password explicitly.
Logging out of identityserver would then also allow to switch identity if needed.
So yes this is possible.
We have an example that does built-in Windows authN (username/password is disabled - but you can re-enable by setting EnableLocalLogin to true here https://github.com/IdentityServer/IdentityServer3.Samples/blob/master/source/WebHost%20(Windows%20Auth%20All-in-One)/WebHost/Startup.cs#L36).
I'm working on a project for an education institution and we currently have live#edu set up with the SSO Toolkit 4.5. We have a portal (home grown) that our users log in to using their AD credentials (local AD only) and then we wire up the certificate to pass up to live#edu so they're not prompted again for login creds when they view their MS mail.
MS is going to stop support for this methodology at the end of the year and so we're now in the process of upgrading our environment to work with Office 365 education. As such, we have set up and ADFS with an Azure AD but I'm struggling getting a process in place where our users still only need to enter their login credentials once on our portal (which is externally facing) and then providing them with a token that will persist on their trip to Office 365. Right now it works as follows: users go to portal.microsoftonline.com and enter their email address. When they tab out of that field, MS checks and finds our domain so then redirects the user back to a login page for our ADFS solution. At this point, users are required to log in again (if they're not already logged in) or they're taken to the MS offerings.
Bottom line, instead of making a "single" sign on solution, they've added more places that our users need to provide their credentials (or just username (email address)).
I'm wondering if there's a solution we can provide to our users similar to the SSO Toolkit 4.5 way of doing things where we can authenticate our users only once on our portal, then provide them access to the O365 services?
I'm not an infrastructure guy at all so I may have provided some misinformation above as to how we have things set up. What I do know from our current implementation is that we need to use "WS-Federation".
I'm wondering if a SAML approach would solve the issue I've described above and let us just challenge for credentials once on our portal page.
any ideas or suggestions would be greatly appreciated.
TIA
This is indeed possible. Read about AzureAD access panel (http://blogs.technet.com/b/ad/archive/2014/10/30/customize-your-app-sso-experience-with-azure-ad.aspx)
1) User will navigtate to https://myapps.microsoft.com/{your_school_domain_name.edu} 2) they will be directly redirected to your ADFS server for signin 3) once they signin they will see the list of apps assigned to them (including O365 apps) 4) click on OWA/SharePoint icon and navigate to the app without having to sign in again.
If you quickly want to test 1) and 2) open an in-private/cognito browser and navigate to https://myapps.microsoft.com/microsoft.com - you will not see O365 or Azure AD signing page - instead you'll be taken directly to the MSIT ADFS signin page.
Hope this helps.
There are several applications that use your domain credentials for login. Eg: Custom Corporate apps. How do you ensure that such applications don't store your password?
The reason I am asking this is: If you are designing an app which does the same thing, how do you convince the user that your app can be trusted not to store the password?
If you really want the user to be sure your app is not keeping their password, don't use their password.
Microsoft Active Directory Domain Logon uses Kerberos. Kerberos is an SSO solution; an application may make use of a user's Kerberos credentials without requiring that the user enter their password a second time. The credentials obtained by the application may only be valid for as long as the user's Kerberos ticket - probably at most a week.
If you have a web application, it too may take part in the warm goodness via SPNEGO. You may have seen this in the form of Sharepoint sites that don't require a login if you are on the company domain.
If you have used standard AD-based Windows authentication they shouldn't have your password but they could certainly perform actions using your user context.
If you provide a username/password to login using standard Windows authentication then there is no way for you to be sure they haven't saved that.
If Windows auth issued login tokens that expired this might be a different story, but I do not believe that is how it works and certainly would still be useless with the second case.