How are you managing access requests for applications running inside AWS?

Question

I'm curious how other teams manage access when employees need to use applications hosted internally or within an AWS environment.

For example, someone needs access to an internal application. Ideally, the process should be simple:

Request access → Get approval → Provision access → Review access → Remove access

The part I'm finding interesting is what happens between the approval and the actual access change. A JSM request can easily capture the request and approval, but how do you connect that approval to the application itself?

For teams using Jira Service Management, are you handling this with automation, scripts, IAM/IGA platforms, or Marketplace apps?

Aditya_miniOrange · Answer

Hi @Emma Phillips ,

This is a good question around access management for AWS resources.

This is where an access governance layer can help bridge the gap between the JSM approval and the actual access change.

With miniOrange Access Governance for JSM, you can define the application, access levels, and approval rules in advance. The workflow can then look like:

Access Request → Automated Approval → Provision Access → Review → Revoke

For example, if an employee needs access to an AWS application/resource, they can raise the request through JSM. Based on the application and access level requested, the request is automatically routed to the appropriate manager or application owner for approval. Once approved, the required access can be provisioned through the connected identity/access infrastructure rather than requiring an administrator to manually process the request.

You can also handle temporary or privileged access this way. If someone needs elevated access to an AWS resource or S3 instance for a specific task, the request can be approved for a defined period and the access can automatically be revoked once that period expires.

The other useful part is the governance layer around it. The platform maintains visibility into who requested access, who approved it, what access was provided, when it was granted, and when it was revoked, while also supporting periodic access reviews.

So JSM doesn't just become the place where the ticket is approved — it becomes the request and governance layer, while the connected identity/access systems handle the actual provisioning.

This approach can work particularly well when you have multiple AWS applications or resources and want to move away from manually processing access changes after every JSM approval.

Sami Shaik · Answer

@Emma Phillips ,

@Nikola Perisic has the request side right (one request type per access target, Assets behind the fields so the requester picks from a list of real applications rather than typing names). The part you asked about, approval to provisioning, is where I have seen three patterns hold up, and one that never does.

Pattern 1: JSM hands off to something that already knows how to provision. The approval transition fires an automation rule that sends a web request to whatever executes changes in your environment: an IAM or IGA platform's API, an SSM document or Lambda behind an API gateway, a CI pipeline, or an ITSM connector. The rule passes the request key, the requester's account ID, the application (from the Assets object), the entitlement level and the approver, then waits for the response, writes the outcome into a provisioning status field and comments the result. The provisioning system stays the system of execution; JSM stays the system of record for who asked, who approved and what happened. The audit trail nobody can argue with is a request with an approval, a provisioning response and a closing comment, all timestamped.

Pattern 2: JSM creates the work, a human executes it, evidence closes it. For applications with no API (still most internal apps), the approval spawns a linked task to the application owner with a form that requires them to attach evidence of the change (a screenshot, a group-membership export). The parent request cannot resolve until the child does. Slower, but it forces the evidence into the record instead of into someone's memory.

Pattern 3: identity-first. If you run an IdP with groups that map to application roles, the "provisioning" is often just adding the account to a group, and the JSM rule can do that itself through the IdP's API. Access review and removal then become group-membership reviews, which is exactly what your IdP is good at.

What never holds: JSM as the source of truth for who has access. The moment someone is added directly in the application, JSM's picture is wrong and nobody notices until an audit. The durable design is: JSM records intent and approval; the application or IdP holds the actual state; a scheduled rule (or the Assets Discovery import if you have it) periodically reconciles the two and opens a request for every difference. That reconciliation is also your "review access" step for free.

If it helps, the shape I would start with for an AWS-hosted app is Pattern 1 with an Assets object per application carrying its owner and provisioning endpoint, so one rule serves every application and adding a new one is a data change, not a rule change.

Nikola Perisic · Answer

Hello @Emma Phillips

As you mentioned this would be something that would be handled with the JSM approvals depending on which person is managing which application within the AWS. For example access for the AWS EC2 Linux machine instance would be it's own sub-request type. It would even contain some of the Assets in order to make the process easier without the need of overhauling the field value, instead using the asset schemas.