I am looking for a bit of direction here. I am building an ASP.NET Core 3.1 web interface to an existing jira tool that does some queries and presents status. For authentication, my calls to the server that retrieve data need proper jira credentials to operate. However, the API I am using never establishes a connection via logging directly into jira. It opens a connection in the code with the passed credentials.
So my question is, what is the proper way to do this in ASP.NET Core 3.1? I don't need someone to do all the work for me, just point me in the right direction. in WPF, I simply had the user enter their name and password and I established the connection object at startup.
Check out these docs. The user shouldn't be putting in their Jira creds in your app.
OAuth 2.0 (3LO) for apps
The app directs the user to an Atlassian screen that prompts them to
grant access to their data on the Atlassian site. The screen displays
the access being requested in the Atlassian product.
The user grants (or denies) access to their data on the Atlassian
site, via the screen.
The user is directed back to the external service. If the user
granted access, the external service can now access data (within the
specified scopes) from the Atlassian site on the user's behalf.
Related
I am writing an internal app where all the users are part of AD. I have the following steps to implement this. Is this correct?
Create Action filter to get all HTTP request to website and check in they are in the specific AD role needed (var isUserInRole = User.IsInRole("M2-ITU-PWApplicationDevelopers"))
If user is not in any of the application roles send user to error page
If user is in application role then Add users to SQL DB and link to Role table in DB so now I have the user/role data ready to use in DB along with other data
When user revisits check the database first before LDAP?
How do I set a cookie or something so that every request does not need through process once authenticated ?
Trying to understand the basics.. Maybe I am going about this all wrong ?
Use Windows Authentication. Your application need to be behind IIS to do it in ASP.NET Core 2.2 and lower, but starting ASP.NET Core 3.0 you can do it with Kestrel alone.
If you do that, you can skip steps 3 and 4. When a person is authenticated via Windows Authentication, the application gets a login token that contains all the security groups that the account is a member of. So User.IsInRole is pretty quick. There is no need to store that information in your own database.
You also don't need to worry about cookies.
The added benefit of Windows Authentication is that it can support seamless login: if your site is in the Trusted Sites in Internet Options, then IE and Chrome will automatically send the credentials of the user currently logged into Windows. The user doesn't have to type in their credentials.
Firefox uses its own network.negotiate-auth.delegation-uris setting for the same purpose.
I have a solution with 3 projects in ASP.NET Core:
MVC --- no DB (calls the API)
Web API --- MySQL 5.7 own DB
IdentityServer4 + ASP.NET Identity --- MySQL 5.7 own DB
I've managed to get authorization and authentication working between all three apps using in memory clients, users, resources following the great documentation found on https://identityserver4.readthedocs.io/.
Currently I'm using the HybridAndClientCredentials flow which works well with existing users as well as registered users. Newly registered users are saved in IdentityServer DB, using ASP.NET Identity tables.
The problems:
One of my client requirements states that the user should have a profile page inside the MVC app to which the user should be redirected after he is authorized & authenticated successfully.
What I'm doing right now is calling the API in the MVC app, OnTickedReceived event, with the initial claims to create the user in the API DB, but I have doubts that this is the correct implementation.
Since the registration is done and persisted at IdentityServer level and some data about the user is stored there, should I make the profile page there too or should I make a call to the API somewhere in the registration flow to create the user in the API DB too, then redirect the user to the MVC app to input the rest of the details required for a complete profile?
Another requirement states that a user should be able to grant read/write access to another user's details (as in linked accounts or something).
Unfortunately, "it depends".
Let's start by asking "what is the profile page?". What information is on the profile page and is that information specific to your application (MVC/WebApi) or the identity management system.
IdentityServer supports the OIDC UserInfo Endpoint and Profile scope with ASP.NET Identity so that could work well. (http://openid.net/specs/openid-connect-core-1_0.html#UserInfo). You can insert IdentityClaims into the AspNetUserClaims table and get those back when you call the UserInfo endpoint.
But maybe this profile page mentioned in the requirements is information belonging to just the application's domain and therefore has no business being in the identity management system. Then, your current approach is ok- though maybe you could use a Filter Attribute instead of an authentication event (that's just a thought, might not be better).
To me, the decision is about who owns this so-called "profile" information. Is it the identity management system or your business application.
If the profile information can be shared across any client of the identity management system, then put it in the identity management system.
So we are using IdentityServer4 for our web applications, all is good.
We have a new requirement from a client to allow them to perform SSO via their ADFS system using WsFederations, we already provide this for another one of our older web applications that is not tied into IdentityServer4 yet.
Ideally we would like to tie WsFedereration into IdentityServer4 so it is in one place.
Does anyone know if it possible to use IdentityServer4, so we redirect to IdentityServer4, identity that this particular client (possibly via an alternative URL), then IdentityServer4 authenticates against ADFS, collects the claims (probably basic, e.g. email/username/etc) , and we then supplement them with additional claims for access, and pass back to the web application.
What I'm trying to achieve ideally is to not change the existing Web Application, and to sort the plumbing at IdentityServer4, and the Web Application wouldn't know or care if this user was IdentityServer4 only or
IdentityServer4 + WsFederation. This would be useful for other clients across our applications to easily integrate in the future.
Alternatively I could deploy another version of the Web Application that authenticates directly with my clients ADFS system. However this seems a waste of server resources/maintenance for just one small client.
I had a look at the external options (where you click google on or near the IdentityServer4 Login Screen), is there a way to automatically redirect to the ADFS without event seeing the IdentityServer4 implemented Login screen.
Is this possible?
Thanks,
Jon
This was released 2017, see the example at
https://github.com/IdentityServer/IdentityServer4.WsFederation
I am developing a REST based application using Web Api 2. On the project, I elected to use the individual user accounts option when I created my project. On the frontend, I am using a combination of angularjs and ios interfaces to interact with web api. I would like a user to enter their credentials and upon successful authentication, receive a jwt token(SSL) that they can use as long as the ticket hasn't expired. I read an article outlining how to create a custom storage provider, which I need as my user schema is different from asp.net identity.
What is the recommended approach to this scenario?
Can someone provide an example of how to setup .net individual accounts for authenticating users trying to access web api action methods? As stated above, the user interface is angularjs.
I'm trying to write a C# console app that will register an application in Azure Active Directory. It should work just as the web application project creation wizard in VS 2013 when you Change Authentication and select Organizational Accounts in Azure.
Following the fiddler trace, I can see that it authenticates the user using wsfederation and an oauth2 token and then uses the graph.windows.net graph api to configuration the AAD directoryObjects service principal and application.
I have tried to use the sample Graph API app, but it requires the app be registered first so that I have the clientId (application id) and password (key) to send in the Acquire Token request using the Windows Azure AD Authentication Library for .NET.
I've tried using a bunch of the different Azure APIs but they all have my chicken and egg problem, I want to use an unregistered client application to register an application in AAD. I need to avoid Configuring Application Authentication and Authorization for the Graph API so that the user has no manual steps.
Does anyone know how Visual Studio does it, using just the user login with browser prompt or if there is a standard application id and password that can be used to access the graph API, like there is the standard login URL, https://login.windows.net/common? Some C# samples would be greatly appreciated.
This post does the Application creation, but requires a clientId and password, which I don't think I have.
You can't register a new application using the Graph API from an unregistered client. The only reason the VS2013 flow works is because VS2013 is already registered in a special way within Azure AD -- it's a first party application and has unique permissions. In my Fiddler trace, VS2013 uses a client ID of 872cd9fa-d31f-45e0-9eab-6e460a02d1f1. Technically you can use this client ID and the redirect URI of VS2013 to initiate sign-on with Azure AD. This still involves user interaction (the user has to authenticate via browser pop-up) so it doesn't meet your requirement for "no manual steps," but it's somewhat helpful for understanding the protocol flows and how registration works.
The bottom line is that if you want to call the Graph API without user interaction (client credential flow), the client needs to be registered with the proper application permissions.