I am wondering if it is possible to use Microsoft's Graph API in order to create a cookie in IE given the username and password, (preferably using C# or VB.net), so that when the user connects to sharepoint with IE, he/she won't have to log into sharepoint via the login screens.
I'm having difficulty searching for examples because most examples describe how to authenticate a user. I am not looking to authenticate a user though, I am looking to create and store a cookie to force a user login.
Thank you for any advice.
No, and this should never be done. First because cookies are simply not secure. Secondly because you should never be storing any encrypted password anywhere.
I'm really not sure how Graph API fits into the scenario you provided. Microsoft Graph is a REST based API. It doesn't authenticated users on its own, you pass in a valid access token with each call. How you retrieve that token depends on if you're using delegated or application permission scopes.
From the scenario you described, it sounds like you're looking for SharePoint Single Sign-On (SSO). There are a few ways to do this but generally it is done using ADFS and AADSync. There is a walkthrough for setting this up: Step-By-Step: Setting up AD FS and Enabling Single Sign-On to Office 365. Be forewarned however, this is not a trivial process.
Related
This is my first question on the Stackoverflow. I have already read the https://stackoverflow.com/help/how-to-ask section and I have read and read and read over the internet to find the connection between OAuth2 and MFA. Which made me more confused. When I take them separately I understand the basic concept.
Background. I am developing a windows application and using mailkit to implement the email there. When I research how to implement MFA on that, most of the answers are talking about OAuth2. That's why I really need to find an answer for this questions.
I have read
https://learn.microsoft.com/en-us/answers/questions/513048/microsoft-office-365-outlook-sending-emails-using.html and https://github.com/jstedfast/MailKit/blob/master/ExchangeOAuth2.md and many more articles to achieve my goal. They all are talking about OAuth2 not MFA.
I am sorry if my questions doesn't make much sense. Please help me to understand this.
Thank you.
OAuth 2.0 and MFA are not related to one another directly.
OAuth 2.0 is an authorization protocol which provides a client application with the delegated access. Way of delegation is defined by grant type and based on the use case you can choose one or another. It does not tell you directly how to authenticate the end user.
For example, using classic authorization code flow you can point the user to login page and optionally consent screen (allow / deny access to the app). An example of URL would be:
https://authorization-server.com/auth?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos&state=1234zyx
Then it's up to authorization server how to authenticate the end user. It can be a login / password screen followed by any type of MFA.
MFA, on the other hand, stands for multi-factor authentication, meaning that there can be 2 of more factors of authentication (such as login and password pair followed by one time code, SMS or anything else).
Based on my understanding of the OAuth2 with Exchange that you've shared, you just need to register an application on Microsoft platform in order to access Microsoft APIs for email sending. That's indeed an OAuth 2.0, but I don't see anything related to MFA there.
Is it possible to pull work items from the DevOps API without needing a user to be logged in to get an access token every time?
I am trying to create a back-end service that pulls work items from the API every so often to generate a report. Can I just generate a one-time access key to use with that back-end service?
I've looked around the documentation, but it seemed like it all requires either a PAT or Azure Active Directory authorization/authentication.
Here's the docs for the API: Link
you can do something like this https://learn.microsoft.com/en-us/azure/devops/organizations/settings/manage-authorizations?toc=%2Fazure%2Fdevops%2Forganizations%2Ftoc.json&bc=%2Fazure%2Fdevops%2Forganizations%2Fbreadcrumb%2Ftoc.json&view=azure-devops
and
https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops
Basically authorize applications to use devops based on your credentials using oauth. similar to an app registration.
Thats the only way I can see without PAT and manual login each time.
Instead of your personal account, you could create a fake AAD user then add it to your Azure DevOps Service.
Use that account to create a Personal Access Token. Similar to Build Service account to pull source code/work items. This should be a easy way to track everything.
But the limitation here is also obvious: this needs involvement of IT department, and also causes additional costs, since every user is billed.
Allow personal access tokens that do not expire is not supported right now. There is a related user voice.
As an alternatively way you could use OAuth just as alphaz18 suggested. Details please refer-- Authorize access to REST APIs with OAuth 2.0
I have two ASP.NET websites, call them Older.com (using ancient ASP.NET WebPages) and Newer.com (which is a combination of WebPages and MVC), with separate login systems. I would like to allow the user of Older.com to be able to link their accounts to an existing Newer.com account, or create an account with Newer.com, and I think I want to do it using OAuth.
As I understand it, OAuth is generally used to allow users to login to a site using an existing account with the likes of Facebook, Google, Microsoft, etc.. However, I might not want to use Google/FB/MSoft accounts to create an OAuth token, but instead use an Older.com password to generate token that also grants them Newer.com access.
Basically, would it make sense to do this using OAuth? Do I have to use a link to an established provider Goog/FB/MSoft to use OAuth? And, are there security issues I should be concerned about when using OAuth?
Any advice, help, experience, or references are appreciated!
edit:
The reason for this is that resources that used to be hosted on Older.com are being moved to Newer.com, because Older.com needs to be rebuilt and the Newer.com is designed around storing and linking related resources. You could think of Newer.com as a place where you can keep an article, but you can also keep all the things related to that article (images, primary sources, derived works), whereas Older.com would just store a copy of the articles with no associated information.
wtyneb,
So there are a couple of ways to approach the problem you've encountered. There are many popular solutions to this problem, but two of them are: OAuth and OpenID. OAuth essentially allows access tokens to be issued to third-party clients by an authorization server. On the other hand, OpenID eliminates the need for webmasters to provide their own ad hoc systems and allowing users to consolidate their digital identities. In other words, users can log into multiple unrelated websites without having to register with their information over and over again.
The main difference between OAuth and OpenID is that OpenID is about authentication (ie. proving who you are), OAuth is about authorisation (ie. to grant access to functionality/data/etc.. without having to deal with the original authentication).
OAuth could be used in external partner sites to allow access to protected data without them having to re-authenticate a user.
In your case, if your users to Newer.com aren't using any information from Older.com, then it makes more of a sense to use an OpenID approach. Implementing OAuth would be over-engineering the solution in this case.
You can provide the credentials by either integrating OpenID into both your Older.com and Newer.com websites, or simply build out the same type of infrastructure into your back end. You can do that by simply exposing a REST API (which you might already be having to authenticate) in your Older.com website. What this does is simply verify the login credentials you have in Older.com when people log into your Newer.com, Newest.com, or any other website you might create in the future.
Please let me know if you have any questions!
In my Windows Store App (c#) I have own authorization mechanism:
User past their account name / password and sent it to server.
Server generate unique token and returns it to user.
For all next requests user used this token.
Now I'm in trying to make authorization with using only Windows Account.
MSDN provide UserInformation class and I can get name for the user account or domain name for the user. But I thing this is not enough for my authorization scheme.
Also method GetSessionInitiationProtocolUriAsync looks very interesting, but I don't know how correct use such Uri for authorization.
How I can use Windows Account for authorization in my application?
note: I'm interested in both situation: when user inside domain or not.
Thanks.
There is numerous was to implement this but if you want to keep it simple and own the process you could implement your own authentication method which on a successful authentication you could build a hash value from their password and secret salt which could be returned to the user as a cookie etc. which you use to validate on every request there after.
On regards to authorisation you can implement your own or use a role based provider linked to the local machine group or active directory by using the classes below or just using the plain old RoleProviders.
You could implement your own method of authentication using the method described below or using the Authentication and Authorisation provider for ASP.Net (if your server runs on .net). Basically the Asp.Net Membership and role Providers. However the method detailed below will allow you to access and modify roles and other information about the user too.
In .Net 3.5+ there is a new namespace called System.DirectoryServices.AccountManagement.
Snippet from MSDN
The System.DirectoryServices.AccountManagement namespace provides
uniform access and manipulation of user, computer, and group security
principals across the multiple principal stores: Active Directory
Domain Services (AD DS), Active Directory Lightweight Directory
Services (AD LDS), and Machine SAM (MSAM).
System.DirectoryServices.AccountManagement manages directory objects
independent of the System.DirectoryServices namespace. Managed
directory services applications can take advantage of the
AccountManagement API to simplify management of user, computer and
group principals. Solutions that previously required intricate
knowledge of the store or lengthy code, such as finding all groups to
which a user belongs, are accomplished in a few lines of code with the
AccountManagement API.
You can easily authenticate a user credential on AD using the code below:
bool valid = false;
using (PrincipalContext context = new PrincipalContext(ContextType.Domain))
{
valid = context.ValidateCredentials( username, password );
}
If you want to validate using a local machine account you can change the constructor too:
new PrincipalContext(ContextType.Machine)
You can check the documentation for other options and additionally this will let you get all sort of information from the store like membership etc.
The new namespace was Microsoft attempt to simplify DirectoryServices which I think was successful but if you want even more control you could use the DirectoryServices classes but that would increase the complexity of the solution.
I hope this helps if you require further information or you think it is not quite what you are looking for let me know I will endeavour to improve the answer.
First, I'm afraid you're confusing authentication and authorization.
Authentication - proving a user's identity (like me presenting an ID when going to the bank)
Authorization - deciding whether an identity is allowed to perform some action (like whether the client "Nitz" can drain account #44422).
A Microsoft account can only provide you with authentication - the client will use some scheme to prove to your server that it belongs to bla#microsoft.com, and it's up to you to decide if it is allowed to do stuff in your application (authorization).
With domain accounts, you can use domain group membership to help with your authorization (it's even common in windows server applications), which you usually get "for free" with the user's authentication token.
Assuming I understood you correctly and you're indeed looking for authentication, you have to provide two behaviors - one for using domain authentication and one for Microsoft account authentication. This is because libraries and communication protocols are very different between the two.
Providing authentication
Using this this tutorial from Microsoft Azure's guys, you can set up a sample application / website combination that utilizes Microsoft account authentication.
To use domain authentication (kerberos / NTLM), you can follow this post and simply enable "integrated windows authentication" in your web site/service (I'm assuming it's IIS). If you're new to enteprise authentication, I'll shortly say that when set up properly (no time differences, AD issues etc.), the authentication is seamless. If there are issues, fall back to a simple "hello world" website and test it from Internet Explorer.
For each scenario, you best create a "hello world" method returning the user's authentication information, to make sure you got it right.
Providing authorization
with each authentication method you end up with a unique ID (Microsoft account: UserId. Domain accounts: SID). Your logic should translate this info to a set of permissions - e.g. Maintaining a table that has the ID in one column, and isAdmin in another. Your application should consult this logic when deciding whether to allow or deny an action from a client.
Combining enterprise and public
Since the methods to authenticate public users are different from the ones used for enterprise users, you'll probably end up with different IDs for the same user when connected from different methods (e.g. DOMAIN\bla and bla.blason#outlook.com). If you intend to provide both authentication methods at the same time, you have to account for that (for example, by creating a "user" table that has one column for Microsoft account IDs, and one for Domain SIDs). It usually makes little sense to provide both authentication methods at the same time, but it's your app.
Hope I helped!
Once i had the similar situation, (A client app need to connect to server with few identity credentials. after the custom authentication , a token will be grant for the client with few claims, then each client request will be validated against the given token) , if you are in something like this, consider this link, it helped me to solve the issue.
http://bitoftech.net/2014/06/09/angularjs-token-authentication-using-asp-net-web-api-2-owin-asp-net-identity/
Note: you can implement custom authentication, and authorization by extending claimsAuthenticationManager and Claimsauthorizationmanager respectively
We have an application which we need to allow users from our customer's systems to be able to sign in without seeing another log in screen.
What is the best way to provide an SSO type experience for our customers? I have tried to research Azure ACS and Windows Identity Framework but they all seem to be based on this idea of a common log in popup/screen which all sites use. Unless there is another aspect to this federated identity system I don't think that will work for us. Basically our customers are education institution which have students who sign in and use their own web applications/portals. These customers purchase access to our application and want their students to be able to click a link from their portal and automatically sign into our system.
From looking around it seems important to know that these systems are running on completely separate domains. For some legacy systems we have asked our customer to provide simple api endpoints for a very custom sso implementation. What I'm looking for is any information about a more standard approach for SSO.
SAML 2.0 is the standard for single-signon. Your clients would need to have some authentication mechanism on their sites that can be translated into a SAML call to your application.
When they sign the student on, they should make a quick call to your application, passing you the username of whoever is logged in. In return, you generate a token, store it in a DB along with the username, and send them the token. They append that token to any link to your app in GET form, and it "uses up" the token (removes it from the DB) but signs them in to that account.
Upon generating the token, you can also remove one "credit" from that applications allowed requests, or whatever else you want to do there.
Our specific needs required us to roll our own SSO type system using some simple secret token handshakes.