Atlassian Guard 플랜 sso saml 정책 문의 (Atlassian Guard Plan SSO SAML Policy Inquiry)

[kimdonghyeon]

안녕하세요,

현재 솔루션에서 자체 IDP서버를 구축하였고 이를통헤 JIRA saml app연동을 진행하여 자동로그인을 테스트 하려고합니다.

현재 자사 솔루션 IDP운용 방식은 saml 플로우가 IDP-initiated 로 구축되어있는데
혹시 현재 Atlassian Guard standard 플랜(무료 30일 체험중)에서는 이를 제어할 수 있는 관리 콘솔 기능이 제공되지 않는 건가요??

관련포럼에서 Atlassian Guard standard플랜으로는 오로지 SP-initiated 플로우만 제공하고
IDP에서 출발하는 idp-initiated 정책지원은 Atlassian Guard premium이나 그 이상의 플랜이 필요하다고 인지했는데 확실한지 문의 드립니다.

추가적으로 premium이상에서 SP-initiated , IDP-initiated 를 조정할 수 있다면 현재 Guard standard플랜으로 무료 평가판 체험중인 플랜을 예외적으로 프리미엄으로 전환 요청 드릴 수 있는지 궁금합니다.


(ENG)

Hello,

We’ve built our own IdP server as part of our solution and are now integrating it with the Jira SAML app to test automatic login.

Currently, our IdP is configured for an IdP-initiated SAML flow. Does the Atlassian Guard Standard plan (we’re on the free 30-day trial) lack any admin-console controls to manage this? I’ve seen forum posts suggesting that the Standard plan only supports SP-initiated flows, and that IdP-initiated support requires Guard Premium or higher. Could you please confirm whether that’s accurate?

Additionally, if the Premium (or higher) plan does allow toggling between SP-initiated and IdP-initiated flows, would it be possible to request an exception to upgrade our current Guard Standard trial to Premium?

Thank you for your help.

[Piyush Annadate _ACE Pune_ · Accepted solution]

Hi @kimdonghyeon ,
Welcome to the Community

Yes, Atlassian Guard (Free or trial - Standard) support SP Initiated; that means Jira (or another Atlassian product) must initiate the login by redirecting the user to your IdP.
Where as Premium supports both SP-initiated and IdP-initiated flows. You can manage this from the Atlassian Admin Console under Security → Authentication policies → SAML SSO, where Premium users get additional options, including:

• Enabling IdP-initiated login

• Custom SAML configurations per policy

• Conditional access controls
  
  
  Anyhow, I would still keep the floor open for an Guard expert to answer. 

[kimdonghyeon]

Hello,

We’re currently running an IdP-initiated SAML flow, but when we’re redirected to Jira we see this error in the log:

error: access_denied  
error_description: authentication-policy-strategy-mismatch

Could this be happening because our Atlassian Guard subscription is Standard, and the policy settings for IdP-initiated flows are blocked? We’ve copied the Identity Provider SSO URL, Identity Provider Issuer, and X.509 Certificate from our IdP exactly into the Jira SAML configuration.

Additionally, we’ve signed up for Guard Premium on a new account and opened the SSO SAML settings—could you please point us to the exact menu where we can enable IdP-initiated login?

Thank you!

[Piyush Annadate _ACE Pune_]

Hi @kimdonghyeon ,
As @Benjamin  stated,  the flow is intact; can you check if you've added authentication policies and verify those and try again?

[kimdonghyeon]

Hello @Piyush Annadate _ACE Pune_ 
Thanks for your answer!!

But please excuse that I have to show the configuration screen in Korean. On the Authentication Policy tab, the only policy-editing screen I see is the one attached. I can't find any idp-initiated options et cetera.
Our current plan is Guard premium plan for 30 days free.
In our IdP-initiated flow, we are redirected to Atlassian, but—as noted previously—the browser does not auto-login and instead shows:

error: access_denied
error_description: authentication-policy-strategy-mismatch

Thank you for your understanding.

[kimdonghyeon]

@Piyush Annadate _ACE Pune_ 

Is there no option in the configuration to control enabling IdP initiated logins in the free Guard Premium 30-day trial version?

[Benjamin]

HI @kimdonghyeon ,

Welcome! Atlassian guard is essentially what you need to integrate Atlassian with your IDP. There is no toggling. Whether it's SP or IDP initiated, depends on how your user logs into the system. If they log through a portal on your IDP, it would be IDP initiated. If the login through Atlassian, it would be SP initiated and redirected to the SSO for Authentication. IT really would come down to where your user decides to login.