Is it possible to do federated identity between multiple instances of IdSrv3 using OpenID Connect/OAuth2 in the following scenario?
Multiple instance of IdSrv3, called Local STS, running on different machines with some kind of chain of trust to a Central STS. The machines running the Local STS can go offline and in that context the applications running on the local machines makes call to local STS for a token and uses that token while communicating with APIs on another server. The API Service, which is registered and connected to the Central STS, can validate and trust the token generated by a Local STS. Is it possible to do this setup with IdSrv3 or IdSrv4? Also how can a chain of trust be established between central and local STS?
That is absolutely possible -
in IdentityServer you can add external providers via ASP.NET (Core) authentication middleware. For the "other" IdentityServer this becomes a normal client.
https://identityserver.github.io/Documentation/docsv2/configuration/identityProviders.html
Related
I have a Java/Spring application that is running on a Tomcat server. The application uses Shibboleth/SAML for getting user access and it works fine.
However I would like to run/debug the application on my local dev environment(on local Tomcat). I wonder if it is possible to set up something and get prompted by the same service provider so that I can log into the application like it is on the production environment.
From https://stackoverflow.com/a/28061252/1534925
[samltest.id][1] is good way to test shibboleth.
You cannot use localhost as SP to connect to remote IDp, that
iDp won't find any SP to return to because localhost means it's own
system so IDp would go in it's local system and find your given SP's
entity ID. It won't find that entity ID so it would give such error.
These two approach may help you
Give your machine some public IP and try connect to IDp with that SP.
If you cannot make public IP, make both SP and IDp in your local system. My [this][2] answer may help you.
[1]: https://samltest.id/ [2]:
https://stackoverflow.com/a/21278524/1534925
and https://stackoverflow.com/a/21278524/1534925
Yes you sure can.
Download and install SP and idP in that machine, configure metadata
for both to communicate to localhost or for better ease use two
domains for SP and idP,
C:\Windows\System32\drivers\etc here add two domains localhost-sp
and localhost-idp to the hosts file.
So you have now two differet domains for sp and idp.
My goal is to create a HTTPS REST service that (in concept) allows a machine account to authenticate using the less- than documented machine$ account.
I have a REST endpoint for an AD connected intranet application. Right now IIS simply echoes the thread CurrentPrincipal when I navigate using Internet Explorer.
Now I'm using the HTTPClient , using default authentication, running a my username, and that also works.
My new goal is to send the AD Connected machineAccount (that ends in the dollar sign $) so that IIS responds with the kerberos name Domain\TestServer$
I attempted creating a Windows Desktop service, running as NetworkService or LocalSystem, and I'm not clear if HttpClientHandler.UseDefaultCredentials is sufficient for running in this (unusual) context or if a different approach is needed to authenticate using the machine account.
Is a PInvoke needed? Is there anything in logonuser32 that needs to be done?
ADFS server 2016 supports openId connect. I have external organization that hosts ADFS server , I want my web application to get authenticated from External ADFS server using openIdConnect .
Question : As per Microsoft docs . If we want to consume external organization's ADFS we should host ADFS in our organization also. My application should trust ADFS hosted inside my organization ,instead of trusting external ADFS directly.
Here I want to know why we cannot directly trust External ADFS using opendiconnect ? It seems possible. what is reason of not trusting external ADFS directly?
Both models work. If your application plans to have users from multiple organizations, it is better to have your app trust an internal org ADFS which can then be federated to multiple of these organizations with simple configuration changes. This makes the application simpler where it is dealing with only one IDP. An additional advantage for having an internal ADFS is that any authentication policy changes can be managed fully at internal ADFS layer and not potentially requiring application changes.
However, if your application is only going to support one external organization, you can do this directly in the application. Both models work for this.
Hope that helps.
Thanks //Sam (Twitter: #MrADFS)
I have a situation where I need to authenticate my application users with SAML2.0. SAML server is hosted at a public domain while our application runs in local intranet.
I wonder, if SAML would support redirecting my users back to the local application (local IP) after authentication.
This is by default or is there any special configuration need to be done in SAML server side?
If the application is being accessed from the local intranet, it will definitely work. There won't be any additional configuration required for that. The reason is simple - SAML uses HTTP Redirects and Form-Post to pass SAML tokens. So if the two applications (IdP and SP) are accessible, it will work.
I have an ADFS server on Azure (available publicly) and the SP is in my local development environment (accessible only on my laptop). It works.
SAML protocol provides the 'RelayState' request parameter for certain bindings. E.g. have a a loot at http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
This allows to specify a target URL for your application acting as SAML SP.
I have a project that have embedded jetty with SPNEGO enabled. I would like to be able to run this project locally for development purposes (WITH SPNEGO enabled!)
My question is, is the SPN and keytab associated with a particular server at all or can I use the same set on multiple instances of my service?
Kerberos requires that both the client and server somehow figure the service principal to use without any prior contact. If you have control of both the client and server, you can use any principal you want provided you configure both sides to
use the same principal.
In the SPNEGO case, the client does the "standard" thing and builds a principal based on the hostname of the server. (i.e. I want to talk to www.foo.com, I'll try
requesting an HTTP/www.foo.com service ticket and see if the server accepts it. )
I don't know of any way to get the SPNEGO code in the browser to use a fixed service principal. So in this case you'll need a separate keytab for each server.