We have ASP.NET MVC applications. We have our own IdP for SSO, The IdP issues authentication ticket using OpenID Connect Protocol. Users can access all our applications by singing once.
We want to use JIRA ticketing system for users to create ticket.
We can create account for every user and provide link on UI to JIRA to create ticket. However that is not convenient if we have large number of users, and keep growing.
We can also create a form in our applications and then submit the form to JIRA using their API. However I am trying to avoid this option because then I have create form in every application and maintain it.
Ideal optional would be, when user clicks on the create ticket link, it should get redirected to JIRA ticketing system, MUST get authenticated implicitly (maybe using access token) and be able to create ticket using JIRA's ticketing system.
Is this possible? Can someone please provide guidelines
You should consider using JIRA's built-in IssueCollector.
This is super simple to set up, and you can find more info here
Unless you need to do something really custom, then this should work out of the box.
Related
I'm mid-way through a task to migrate a legacy .NET MVC app to use Single Sign On (SSO) to make integration with a to-be-developed mobile app possible. I'm planning on using Azure AD B2C to facilitate this and based on my researched, I need to use custom policies to achieve the required functionality.
Work on this migration is proceeding very slowly. I'm finding the custom policy XML very clunky to work with. It's going to take quite some time to achieve parity with the existing system given the current velocity. I'm wondering whether it would be wise to sidestep a lot of the migration headaches by using the Microsoft Graph API in place of custom policies.
Take registration for example. It appears common to redirect the user to a SignUp.xml custom policy (or the integrated SignUpOrSignIn.xml) to handle adding the user record in the AD B2C data store. Part of this policy would involve calling a REST API to create a corresponding record for this user in the app's database (stores email settings and such). Instead of using these custom policies, my plan would be to instead take the existing registration process and simply add a step which creates the user record on the B2C side using the Microsoft Graph API.
It appears like most things I need may be achieved using the Microsoft Graph API. Things I'd need that I can see are not available are:
logging in to a user account and;
sending verification emails
Are there any other common authentication-related tasks I'm likely to need that couldn't be achieved using the Graph API?
As far as downsides, the fact I'd be handling user passwords (even if it was just to create the user and nothing else) is an obvious concern, but perhaps acceptable. The main thing I'm after is a simple SSO solution that generates secure access tokens (incl. handling reset tokens, etc). I hope then, that this could be a feasible option.
You will miss out on password reset, profile edit, SSO and token expiration etc.
A better way may be to use the base custom policies and achieve a lot of what you need by having the policy call REST API's.
What is your use case?
I recently switched to a new company where my manager wants me to develop entirely new cloud based project in MVC. I have never worked on a project from the start and I think this is a good opportunity for me to lead.
However, I think the requirements of the clients are bit confusing.
Here is what he wants:
Client should be able to access the cloud hosted application from his network with single sign on. He wants to use his active directory for that.
There are different users in active directory, they will have different roles (I think we can handle this on database side. Create different roles and assign roles to users).
Client has to add vendor info in the application. But for this, system should send an email to vendor with the url of the cloud application. He wants user to login to the application using 2 Factor Authentication. So, send dummy password with url, and send OTP to his mobile number. Just like registering to any system.
Now my questions are:
Is it possible to have 2 different types of login mechanisms in the same application? SSO for client and 2FA for outside vendors?
If yes, could you please guide me in the right direction?
what things I need? Which framework, design pattern should I prefer?
How do I proceed ?
I am trying to get Sitefinity to work with MVC and JQuery Mobile and am having many issues....
The current issue is that I need to have users authenticate to access parts of the application. This authentication needs to be with an external service, the users logging into the front end will not be in the Sitefinity user base. I also need to have users who can log into the back-end to update the content, these users will be managed by Sitefinity.
To secure pages in MVC I add a authorize attribute on the controller. This needs to confirm the users on the front end have been authenticated by the external service, but still allow users logged into the back end to be able to updated content.
This is not working, when I hit the page with the authorize attribute on the front-end it is trying to take me to the sitefinity login. Has anyone found a way to make this work?
Well, I have a way to do it now, but I'm not all that excited with it...
I heard back from Sitefinity support and was given a few different ways to do this.
1) Create my own custom AuthorizeUser attribute, save the values when I authenticate to the session of a cookie, check for that value on the attribute...basically rewrite all the Authenticate functionality myself. - I'd really like to keep the Authenticate functionality as much as possible so I don't think I will do this.
2) Create a Custom Membership Provider, add this to the Sitefinity backend as a valid membership provider. This would be a good solution if I was wanting to store my users in a database and validate/update them. But, I am only validating against a service.
3) Create a dummy user in the Sitefinity backend with no access and definitely no backend access or admin access. After authenticating to my service if all is good then log into this user from the code. After this the [Authenticate] attribute finds that this user is logged in so all is good. As I do not need to check roles or claims in my app, just that user is logged in, this may work. It seems pretty ugly to me but I am assured that as long as the user does not have backend access or admin access it will not count to co-current users and many many users can be logged in as the same user.
I will go forward with option 3 and see how it goes and if I can get it past the architecture team.
here is the link where I found option 3 with some more info...
http://www.sitefinity.com/developer-network/forums/sitefinity-sdk/custom-authentication
James!
Not sure but I think your 3rd party service should use the Sitefintiy Single Sign On.
Maybe the following help topic on how to setup Sitefinity single sign on will be helpful:
http://www.sitefinity.com/documentation/documentationarticles/authentication-models-overview
I'm working on an MVC4 site using SimpleMembership to handle user accounts and role based authentication. We have another site and we'd like to implement a single sign on system allowing users from the existing site to log in to the one I am building. What would be the best way to achieve this and hopefully leverage to the existing roles based authorization I'm using on the MVC4 site. Is it possible to have multiple membership providers (i.e. use the built in one and if the user is not found, attempt to authenticate via a custom provider that I'll write (once I work out how!). Or would it be better to abandon the built in membership/roles and roll my own?
I also thought of letting WebSecurity check the local database and if the user is not found, query the 2nd database and if the users credentials are valid, create a local account for them. One issue with this approach is if a user called Fred registers on the MVC site, and then a user from the other site called Fred logs in, we couldn't create them a local account with the same username. We could prefix/suffix the username with some text to indicate that they are from the other site but then we lose the single sign on feature.
We will also want to integrate AD authentication for staff in the future.
So essentially I'm looking for the best way to authenticate users from multiple databases and keep using roles based authentication?
I've also done a little digging was wondering if ADFS might be useful for this.
Any help or advice would be greatly appreciated!
I recommend the use of an Identity server to handle all your login request and switching to a claim based authentication instead of a role based authentication if you can.
I personally went with Thinktecture IdentityServer
pluralsight.com have a good course on it.
Thinktecture IdentityServer is build on top of simple Membership and it supports multiple protocol such as
WS-Federation
WS-Trust
OpenID Connect
OAuth2
ADFS Integration
Simple HTTP
I recommend checking it
Good Luck
I want to display JIRA details such as issue titles, a version roadmap, and the issues raised/resolved graph for projects in a Confluence site. This is fine for folks that are logged in but I need it to work for anonymous access as well. I don't want to have to set up anonymous access in JIRA for the project as it contains other details in the comments, etc.
I have followed everything that I can find as far as setting up Application Links between the two and can get the issues to display if I enter an account in the Basic Access tab of the application links.
Using the developer tools in the browser I can see an OAuth error when the gadget on the Confluence page tries to make a request.
Is there a way that Confluence can impersonate another user when it queries JIRA?
Seems to me that you want to do something impossible. As I understand it, there are the following options for using JIRA content inside Confluence:
Use the authenticated user of Confluence in JIRA.
Use an anonymous user for public issues in JIRA.
Use a pre-determined user (not recommended): This will show in public the user name and password in Confluence.
So you have the following options:
Use issue security in JIRA, and set the comments in your issues only be available for a special group.
Ensure that the users you want to get access to are not contained in the special group.
See the documentation about "Trusted Communication", especially the following part:
Display the JIRA issues which the logged-in user is authorised to see. And if the user is not logged in, display only issues which allow unrestricted viewing.