I have two projects in JIRA: software project and service desk project.
My goal it to enable my service desk customers to access the software project but in a limited way. E.g.:
clients could create stories,
comment on them,
assign priorities
and assist with assigning them to iterations / releases.
But they would not be able to perform and see some actions e.g.:
see the logged time
and ideally to keep some of the ticket / story fields and comments as internal use only so I can have technical discussions with my team without the client seeing them etc.
I can see in documentation that "Service Desk Customers can't log in to JIRA applications":
https://confluence.atlassian.com/servicedeskcloud/setting-up-service-desk-users-732528877.html
But is there any workaround to give Service Desk Customers access to JIRA applications? Is there any simpler method than making a REST API bind? If yes, then how it could be achieved?
The documentation is not clear. Add their accounts to the jira-users group and they will be able to log into JIRA as regular users. The point is that member of jira-users consumes a JIRA user license, while "pure" customer account does not.
As regular regular users they will have permissions just as you configure your project Permission Scheme, so everything is in your hands. Using roles you can restrict issue comments to those roles. There's also nice Comment Security Default plugin to use with that.
Related
We are currently review our user access permission for Azure. We want to review and further refine the existing/built-in roles that came with Azure. For example, the Contributor access may be a bit too much in some instance. Specifically, below are two roles ware are trying to create:
DEVELOPER: Currently our Developers are assigned Contributor by default. The issue here is that this gives them the ability the create/delete resources as will. Resources are typically pre-created by the Cloud Team. We want to limit that. Ideally, we want to give them the ability to configure resources and start/stop rescues.
OPERATOR: This is for our IT folks who need to review resources and start and restart resources. Similar to the Developer roles above, they don't need to create/delete resources.
Any suggestions or roles examples that can help achieve the above?
Thanks
You can use Azure Custom Roles. Take a look at the Azure Portal Tutorial and the Azure resource provider operations.
Is there a way to share Jenkins service endpoint credentials across multiple TFS projects? We have close to 30 projects, and each build requires us to configure the same set of credentials.
I would like to set an environment variable or something that would allow us to manage those credentials in one place for all TFS projects.
For a specific project, you click the gear here:
And then enter the credentials here:
This is not possible yet, there is a Feature Request about it, you can up vote there.
To automate the process you can create the Jenkins endpoints with the Rest API Endpoints - Create.
No. Service connections are scoped at the Team Project level. Team Projects are intended to be largely isolated from one another, so there is limited ability to share things between them. If you need to manage a service endpoint across many projects, you'll need to look at the REST APIs and write a programmatic solution.
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.
I'm working on a service that provides smart (hopefully) integration of different services supporting OAuth 2.0. The focus of our tool is on team work flow improvement, so we're combining Slack, GitHub, Asana (issue tracker), Cezanne (hr tool), etc.
We have ui and backend that work with all those tools (user is authorised to all of them, so I have required access and refresh tokens). We need to be able to hide different parts of the ui depending on person's role in a specific tool. Let's take GitHub as an example. The user can be a repository owner, contributor, company owner (for business account), etc, so those user might need different ui based on their rights.
Originally I was hesitant implementing authorisation on my own (another custom authorisation system is the last thing this world needs), I wanted to take advantage of other services' authorisation mechanisms and just create a lightweight wrapper around them. It seemed like a reasonable idea at first, but I can't figure out how to implement it and Google doesn't give valuable advice which means: 99.99% I'm trying to do something stupid, 00.01% I'm trying to do something rare/innovative.
I hoped to take advantage of OAuth 2.0 but it doesn't seem to support what we need. The closest thing is scopes but it doesn't look very relevant to our scenario.
The only idea I have for now is to create our own authorisation system and integrate other services using kind of reverse engineering. So I would request user's GitHub account details using API and apply him roles in our system appropriately: Owner for repository A, contributor for repository B, owner of company C, etc. I will have to reverse-engineer the permission for each role (i. e. repository owner can not change company name). And we would have to keep user roles for each service: so instead of typical Admin/User/Manager/etc. we will get: OwnerOfGitHubRepository (for repositoryA), ManagerOfAsanaTeam (for team B), etc.
It would be awesome if OAuth 2.0 services had an endpoint that would return the permissions available for a current user.
I'm not a security engineer, so I might be missing something obvious. So wanted to ask you guys for advice before investing into the implementation mentioned above.
The word, "authorization", is used in two different contexts.
In one context, authorization means "who has what permissions". Solutions for this authorization is "identity management".
In the other context, authorization means "who grants what permissions to whom". Solutions for this authorization is "OAuth".
In some cases, you may have to handle these two authorizations simultaneously. See this question and this answer for details.
You tagged your question with identityserver4.
This Issue for identityserver3 from last year may interest you.
But I'm afraid most providers don't support this oauth2 profile (yet).
UMA seems to be an oauth2 way to enable fine grained authorization, but may not be the best solution.
Service or daemon authentication to the Microsoft Graph grants access to a limited number of functions.
For example, to be able to work with Planner and tasks, you have to be logged in as a user. In other case, we can't access most of user details, we can't access user's files and so on.
Why service or daemon must have more permissions then now? In our case, service should automatically create Planner tasks and Calendar events for specific users or groups according to automatically registered events. Sometimes it should also create or add or read files in OneDrive of this user. Also automatically, of course. Due to Microsoft Graph restrictions, it is easier to use additional 3rd-party service to track tasks, or even write our own. The same situation with files.
Microsoft Graph looks like a powerful API, but due to its access restrictions it becames unusable when you need to made something automatically, without any user actions.
What is the reason for most of these restrictions?
Is there any walkarounds?
Office 365 works perfect with deamon applications but not in your usecase. It works great for modifying a user' calendar for instance. See here https://learn.microsoft.com/en-us/graph/api/user-post-events?view=graph-rest-1.0&tabs=cs
Apart from that, if you want to have something changed in the graph api. The best way to let Microsoft know is to create an item on UserVoice. This is to let users influence what features they need, maybe you can express your wishes there. https://microsoftgraph.uservoice.com/forums/920506-microsoft-graph-feature-requests