SSO and Fusion Lifecycle

[richard.valdez]

So we all know Fusion Lifecycle is not Part 11 Compliant, so to get around that we are using the OKTA SSO system for Fusion's compliance issue. but It appears to me that we have another issue by using the OKTA SSO system.

we are granted third party licenses for anyone we see fit to login to our tenant. BUT by using the OKTA SSO, we cannot have anyone outside the company login to our tenant. Our OKTA SSO is limited to only our Company email so I don't think this third party license deal is possible given our Part 11 regulation. so this kind of works back to the thought - I think Fusion Lifecyle needs to figure out how to incorporate a Part 11 Compliance feature that can be used if a company wishes. (so we don't have to use OKTA SSO) because right now even if we wanted to give a third Party license out, we would not be able to...

[tony.mandatori]

Richard,

I thought we could request a mixed mode configuration where you could use either the Autodesk ID or the SSO login.

Have you tried contacting Tech Suport on this issue?

Thanks,

Tony

[richard.valdez]

I believe we circled this option and it came back to Autodesk does not allow both. from our last conversation it was an all or Nothing type deal. either we have SSO turned on and only ablr to access through OKTA or off and we sign in without it. but with out it we are not in compliance with the FDA Part 11. 

[gasevsm]

You can request hybrid mode Yes, from the view point of the tenant, and not the user ~ the user gets no choice how to login: everyone with corporate email in their AutodeskId Must use SSO AuthN, others outside the corporate domain Must use AutodeskID. This gives you freedom to evaluate if wish to manage external third party and supplier accounts as AD accounts within your domain which would enforce SSO auth or only Manage employees in AD.
HTH,

[gasevsm]

Hi Richard,
You can continue to assign 3rd party licenses to non-employees AND create/manage AD accounts for them using your corporate email domain. This way you can manage authN policies for everyone or anyone using your IT procedures. Generally, the authentication model is orthogonal to the licensing model ~ how users login is irrelevant to what license they have. You are responsible to remain compliant with our 3rd party licensing requirement and audits assigning them solely to external audience.
We are actively working towards supporting multiple corporate domains bounding to same tenant. This would allow your suppliers to also use own federated identity and own AD accounts including own identity brokers different than your okta if needed, yet all participants use with corporate authN. Timeline for supporting this is projected for spring release.
HTH,

[richard.valdez]

so if we decided to turn on this Mixed Model/ Hybrid version what web address should the Third Party users got to? if I have them go to: 

https://mesalabs.autodeskplm360.net

it directs them to sign into our Okta SSO Page (which they do not have access to... 

[tony.mandatori]

In mixed mode, users without a corporate ID should not be redirected to the SSO page.

[richard.valdez]

so they still type in https://mesalabs.autodeskplm360.net and it takes them to the Login page not our SSO? I guess my question is if you are a Third Party User, how would you access my tenant? what Web address do I give you? @tony.mandatori

[gasevsm]

Remember in mixed mode, user cannot choose authN path, User will have a chance to enter email address.
- If users' AutodeskId account email address is @mesalabs.com domain, they will be auto-directed to your SSO page.
- Otherwise, they will be directed to classic AutodeskId.
- If employees even try to go to classic autodeksid with mesalabs domain email, our auth will deny them that path and direct them to SSO.
- all people that have email that is not your domain must use Autodesk ID auth.

[gasevsm]

Remember in mixed mode, user cannot choose authN path, User will have a chance to enter email address.
- If users' AutodeskId account email address is @mesalabs.com domain, they will be auto-directed to your SSO page.
- Otherwise, they will be directed to classic AutodeskId.
- If employees even try to go to classic autodeksid with mesalabs domain email, our auth will deny them that path and direct them to SSO.
- all people that have email that is not your domain must use Autodesk ID auth.

[gasevsm]

Sorry replied via cell's outlook directly and it posted my last response twice. I wanted to give you addendum for better details. Namely, we've always supported mixed mode from the get-go. This isn't something we introduced along the way. So here's some more clarity:

In case of mixed mode and multiple suppliers. You are in control to create AD accounts for your most
Trusted suppliers and give them mesalabs.com email address. And you will create plm accounts assigning them 3rd party license (as they are not employees) for them with that email. You will manage domain password and policy for them. Those folks when they hit plm site, if they wish to login they will provide the corporate email you've given them. The system will direct them to your SSO page where they enter domain credentials you've given them.

For semi-trusted suppliers, you may choose to not create AD accounts. You'd still create plm account reservations setting their respective @supllierA.com email addresses and assign them 3rd party license; on their attempt to login they will enter their Autodesk Is username or their own email address and the system will Direct them to authenticate using Autodesk ID auth.

In both cases, this is authentication mechanism which is orthogonal to the licensing model and also orthogonal to the authorization. Licensing required to not assign 3rd party licenses to employees, but only to non-employees regardless of how they login. And the plm authorization will kick in the moment they authenticate and assign the proper permissions throughout the tenant that the admin has given them regardless of how they've logged in.

Hope this is clear?

[richard.valdez]

When going to mesalabs.autodeskplm360.net the user is redirected to Okta immediately upon clicking Sign In. so how does the third Party License access it outside of our OKTA Sign in? is there a different URL they go to? 

[gasevsm]

Richard, your tenant is configure with exclusive SSO mode, thus anyone and everyone is redirected to your corporate SSO login page. Here you can create AD accounts for your contractors and have them use the saem AD authentication. The alternative is we switch your tenant FROM:ExclusiveEnterpriseSSO mode TO:HybridEnterpriseSSO mode. To have this mixed SSO mode would mean users still go to the Login page on mesalabs.autodeskplm360.net, then they land at a fork in the road: either they use corporate auth or autodeskid auth. Your employees must go to the left and use network credentials, whereas your contractors whose PLM users have non-mesalabs.com emails would go to the right and use own AutodeskID auth. We cannot choose for the user for we know nothing about them when attempting to sign in to your site, whether they are member of your domain or not, regardless if they are employee or contractors. You have full control here which of your contracts you want to control authentication via AD and Okta, and which you want to have continue logging in via AUtodeksID.
Does this help?

[gasevsm]

Richard, your tenant is configure with exclusive SSO mode, thus anyone and everyone is redirected to your corporate SSO login page. Here you can create AD accounts for your contractors and have them use the saem AD authentication. The alternative is we switch your tenant FROM:ExclusiveEnterpriseSSO mode TO:HybridEnterpriseSSO mode. To have this mixed SSO mode would mean users still go to the Login page on mesalabs.autodeskplm360.net, then they land at a fork in the road: either they use corporate auth or autodeskid auth. Your employees must go to the left and use network credentials, whereas your contractors whose PLM users have non-mesalabs.com emails would go to the right and use own AutodeskID auth. We cannot choose for the user for we know nothing about them when attempting to sign in to your site, whether they are member of your domain or not, regardless if they are employee or contractors. You have full control here which of your contracts you want to control authentication via AD and Okta, and which you want to have continue logging in via AUtodeksID.
Does this help?

[benderk]

Thank you for submitting your idea. Have you tried the Modern Interface lately? We request that you review your idea in the context of the Modern interface. If your idea is not addressed, we invite you to create a new Idea in the context of Modern so that it can be addressed accordingly. Sincerely, Keri Bender | Global GTM Business Strategy Manager, Product Lifecycle Management

[amitabh_verma]

Change to Implemented