Is there any quick IdP for IGEL Onboarding test that doesn ́t need a credit card for free demo, like Azure AD?
Hi, so only for testing, one shot?
Yes, only to show it on Demos for customers
IGEL support is currently for IDP via Azure Active Directory, Okta and Ping)…
Should work with another IDP that support OAuth
Steps 4 and 5 from above sequence diagram
I wonder about something like…
I know that but:
• Azure AD needs credit card for free demo.
• Okta. I tested it, but had some errors and I was busy these days. Demo time finished.
• Ping Identify. I ́m testing it, but don ́t find the need it info for IGEL Onboarding.
I will try keycloak. 😉
@member could that be a usecase for our Testdrive?
Hi gentlemen 🙂
@member FYI Azure requires a credit card but nothing is being charged if you just use the azure app required to demo onboarding
@member yes it could, but our Cosmos Testdrive isn’t ready yet
@member Keycloak works, it uses open ID connect I believe, it needs some config tweaking as our OS is locked to the supported IDP’s by default (see screenshot)
I ́m testing with AUTH0 (Similar to Okta) and shows these messages after user login during Onboarding:
“`TypeError: Cannot read properties of undefined (reading ‘toLowerCase’)
at Layer.handle [as handle_request] (/usr/share/obs/node_modules/express/lib/router/layer.js:95:5)
at next (/usr/share/obs/node_modules/express/lib/router/route.js:137:13)
at complete (/usr/share/obs/node_modules/passport/lib/middleware/authenticate.js:271:13)
at pass (/usr/share/obs/node_modules/passport/lib/authenticator.js:428:14)
at Authenticator.transformAuthInfo (/usr/share/obs/node_modules/passport/lib/authenticator.js:450:5)
at Immediate._onImmediate (/usr/share/obs/node_modules/passport/lib/sessionmanager.js:51:9)“`
Any idea? Seems related to Java
Try to follow note here to debug OBS
Q: How to test OBS connection?
A: Open web browser and connect to `https://firstname.lastname@example.org`. Use the browser developer tools to look at returned content. Here is link to developer.chrome.com/docs/devtools/ Chrome DevTools
That ́s what I tested and shows that error.
With customers tests shows “done”.
Now, one has error 37 Failed to get CA certificates from server and the other error 33 Failed to initialize EST API, but I don ́t know how continue to investigate the real cause.
I would look at the web cert and make sure NTP time is running…
Which “UMS Hostname” must to be typed here? Internal network UMS IP, public UMS IP or URL, same name than appear on UMS Web app, etc.
Public facing FQDN — that should be in the cert
Do you mean this? If not, which file I need to verify to confirm it?
from the internet can you access UMS hostname on port 8443 is it open?
“`nc -v -z your-fqdn_ums 8443“`
Obvisouly not, because Hostname is my internal IP Adddress but, IGEL Onboarding is not a service that allows to securily register remote devices without ICG or direct connection to UMS?
If remote devices need to access directly to UMS public IP is not needed Onboarding via Azure account, because you can do it easily with OTP or Radar methods.
Perhaps we didn ́t understand its function well. :thinking_face:
This is correct, OBS over Azure IDP is optional, you can work with IGEL Cloud Gateway or Token based.
Our customers main reason to work with OS12 is to not use ICG and can register devices remotely without it or a direct network connection to UMS.
Remote devices must access to UMS server IP, with a VPN for example, to register when Onboarding is configured? Then, I don ́t understand utility for OBS and the only method available to register remote devices avoiding UMS server access to/from Internet is ICG12. True?
The OBS only tells the device where to find its Universal Management Suite. You need an access Device => IGEL Cloud Gateway => Universal Management Suite
Device => Universal Management Suite
to get it working.
OK. All clear. I don ́t know why we thought that was Device > IGEL Customer portal > Azure IdP > Customer portal > UMS
I think that we will use ICG12 for remote devices.
I suppose that local registered devices must to register again, but via ICG, when they are out of the office to access from UMS, true?
No, that‘s the magic of OS12:
Just to confirm:
1.- Remote devices cannot be registered via OBS if they have no connection to UMS directly (VPN or ICG).
2.- Locally registered devices can be managed with UMS when they are on remote if we use Web certificate. No needed to re-register via ICG
1) yes, but no VPN needed, port access is enough
2) if they can reach the public fqdn over 8443. correct
Is possible to do OBS with NAT instead direct access to UMS IP/URL and port 8443?
Q: Is ICG 12 needed with UMS 12 for OS 12 devices not on the same network as the UMS 12?
A: That depends on if your security team will allow UMS 12 on port 8443 to be opened to the Internet or connected to internet via load balancer with SSL pass through (such as F5 / NetScaler / Azure Application Gateway with end to end SSL/TLS encryption and WebSocket support) that forwards encrypted SSL traffic to the UMS without decryption. If the above options cannot be met, an ICG 12 will be needed to support OS 12 devices. Similar sizing guidelines for ICG 12 (setting connection limit to 2K / 2.5K devices). See kb.igel.com/igelicg-12.01/en/igel-cloud-gateway-icg-81512143.html ICG 12 KB.
Thanks for the info, but customer ask for do a simple NAT on his router to access from remote device to his UMS
Well I would test… but as long as router forwards encrypted SSL traffic to the UMS without decryption then I would think it could work.
Continue reading and comment on the thread ‘Is there any quick IdP for IGEL Onboarding test that doesn´t need a credit card?’. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.
Submit a question, or Join Today!