I am working on a service that logs into JIRA and performs few operations that are not associated with a particular user. Right now, I'm using a virtual account and authenticating the JIRA by the accounts username and password. The use case requires a significant number of such services to be created. The current solution will be messy to maintain, because I need to keep a track of service level logs, which will require creation of a large number of virtual accounts, whose management is difficult. Is there a service account like concept in JIRA that allows a service to perform authentication as an application like on Google cloud?
Their reference about the REST API.
I played with it once, remember it requires API key or token maybe.
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?
There used to be a way for an anonymous user - such as a script - to query certain aspects of Jenkins via its REST API. For example, finding out the name of a user who started a particular build job, or the date it executed. However the security model changed in the last few years which seems to make this much more difficult, even for read-only access.
I'm using Jenkins with ADS authentication. I need to provide API access to a script, but I don't want to use a particular user's personal API token (hard-coded in the script) because the script might be run by anyone in my organisation, including as part of other automation, and I don't want to tie this to a specific employee.
Instead I need a job-based token - one which is set for the job. There's a build token, but I don't think this works for the REST API.
I thought about creating a special "auto" user, and creating a token for that user, but the Active Directory config seems to prevent me from creating new Jenkins users. I cannot create a new AD user because I simply don't have the ability to do that in my organisation.
What's the best approach to using API tokens for anonymous access? Also, is there a way to ensure the token only provides limited access - e.g. read only? Ideally such a token would be restricted to a specific set of jobs, rather than global.
There is not. Feature request is JENKINS-56465.
See https://stackoverflow.com/a/49938577/97831 on how to add users to the Jenkins database with authentication already enabled.
API tokens are the same as password, functionally speaking. If you could do it with the password, you can do it with the API token. If you want an API token to have read-only access, then the user it's associated with should be restricted to read-only access.
some questions about service accounts and best practises on GCP.
1) I'm able to create a "brand new" service account. How can I ensure that this new service account doesn't have any kind of privileges bound to it? I'm asking this because for a project I need to create multiple service accounts with only one permission: write access to a single Google Storage bucket. Nothing more. How can I ensure that this is the only granted permission and nothing else ?
2) Should I create a new Google Cloud Project for every customer I have, in example, one project for each website that I'll host to GCP or a single company project (in this case, my company) would be enough to hold all Compute Instances, Storage buckets and so on, needed by my customers ?
Managing hundreds of project would be overkill, if possible, i prefere to avoid this, without impacting secutiry.
Thank you.
You can only constrain service account permissions to enabled services that implement IAM (the Google Cloud Platform services including Cloud Storage). For services that don't implement IAM, the only way to limit a service account's auth is through OAuth scopes.
Projects appear provide a more robust security perimeter for you to separate your tenant customers. Additionally, you get enforced separation of billing, logging, auditing etc. It's debatable whether managing per customer projects (each owning a bucket and related service accounts) has different security than a multi-customer project (with many buckets and service accounts) since service accounts may be easily extended across projects. I recommend whichever path you choose, you ensure control is effected programmatically to minimize human error of granting one customer's account(s) to another customer's bucket(s).
HTH!
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
I am developing a python app running on embedded linux to access office365 calendar via the EWS interface. I plan on using impersonation to access data.
I have registered my app with azure AD and retrieved the endpoints which contain a tenant id. But I have learned that using the common endpoint seems to work just fine in refreshing the access token.
what are the advantages or limitations in using the tenant id instead of just using common?
Take a look at http://www.cloudidentity.com/blog/2014/08/26/the-common-endpoint-walks-like-a-tenant-talks-like-a-tenant-but-is-not-a-tenant/. The common endpoint does late binding to the tenant based on the users login details. The article does add "For line of business applications you do NOT want to late bind the tenant, in fact you want to ensure that the caller comes from your specific tenant and no other! In that case, use of common is not appropriate."