Can someone explain what a relying party trust is. I am configuring IFD for CRM but I cannot find basic information on what a relying party is and what is does?
The way I would describe this is that CRM is the relying party, it is relying on ADFS to check the claims that are made ("I claim that I am userX").
In ADFS you configure a relying party trust to tell ADFS where it can expect claims to come from - it will trust the relying party so that when a user is authenticated they can be redirected back to that application (you don't want to give a user a token to present to an application you do not trust).
ADFS allows federation which comprises two sides viz. the IDP (Claims Provider) (the owner of the identity repository - in this case AD) and the RP (Relying Party) which is another STS or application that wishes to outsource authentication to the IDP.
Trusts are handled via certificates based on the ownership of private keys e.g. SAML tokens are signed by the IDP.
So the RP trust is the trust between the RP and the IDP - a token signed by the IDP must originate from the IDP and therefore the claims inside the token can be trusted.
Related
I am setting up basic SAML support for a web application. Each user this application (identified by email address) can belong to multiple organisations/companies of the application. I would like to let individual organisations to enable SSO via SAML for users that are members of their organisation.
The communication between me (the SP) and the Idp (e.g. Okta, OneLogin) works just fine from the technical side. But I haven't figured out how to ensure that a user requesting access to my application via SAML is actually the user who she pretends to be, given that she might have signed up for a user profile before SAML was enabled for the organisation.
Is there some sort of "linking" that needs to take place in order to "connect" an existing user profile with a specific Idp?
An IdP contains a set of user identities. When your SP and IdP exchange its metadata, you set a circle of trust, so all users that the IdP contains will be trusted by the SP.
Some IdPs has the ability to restrict what users access what SP, or the ammount of information of a user will be send to the SP, but at the end, you as SP may trust all the info that the IdP provides.
I'm adding SSO feature to my service to allow customers login with their AD accounts. To provide this I use SAML component from componentpro.com
What is correct way to perform security interaction:
From IdP side: what should customer provide to my service besides IdP url? Any certificate that just contains public key?
From SP side: what should I provide to customer?
Choosen SAML tool uses certificates to sign SAML request to IdP and to decrypt assertion from IdP. What are that certificates (from previous questions)? Is it the same certificate for signing and decrypting?
Update: useful link about using certificates in SAML communication.
Normaly this is set up using a SAML metadata file that contains the IDP endpoints, keys etc. Your service then sends a similar metadata file with information about your service to the IDP
If the customer is the IDP then as above you usually provide them with a metadata file.
It is gennerally a bad idea to use the same key for signing and encryption. Read the discussions here and here
When we look to OpenidConnect flows, your solution does not match with.
It's to The identity provider should make this EndUser Authentication with LDAP Directory , not the Relaying Party. "mod_auth_openidc" play the role of a Relaying Party not an Identity Provider.
Can you please tell me what do you think ?
Apache2 Reverse Proxy with authentication over OpenID Connect and authorization over ldap
The use case is that the Relying Party may choose to apply authorization rules based on locally stored data such as application roles to grant permission to protected resources to a user who was authenticated against a 3rd-party Identity Provider.
We're using OneLogin w/Active Directory to achieve Single Sign On with a SAML enabled 3rd party application. We would additionally like to perform API calls related to the 3rd party app. The API calls require a 'basic authentication' header which depend on the 3rd party app's username and password being available. Is it possible to retrieve the username/password information through OneLogin for a SAML integrated application?
From what I understand, apps integrated via SAML or OAuth do not store their passwords with OneLogin. Which means I cannot look them up in our integrated Active Directory (they would be encrypted anyway). However... if during user provisioning, I were to force all 3rd party accounts to have the same username/password as the OneLogin account... might that work?
Any assistance or suggestions would be appreciated. I have some flexibility to work with here as we have not yet created any OneLogin or 3rd party accounts.
Passwords are not provided by the SAML protocol.
You will find this thread interesting:
SAML assertion with username/password - what do the messages really look like?
Alternatives:
Use SAML on the API calls (Oauth2 SAML2 token).
When provisioning the user account on the 3rd party app, force the user to set a local password to be used on the API calls.
I understand ACS is being phased out in favor of WAAD. As I prepare to delve into Azure for the first time I have a few questions. I already have an Azure account (linked with my MSDN account).
Under ACS, I would create a namespace for my application, configure it with Idps and claims mapping. I would point my application (a RESTful API via WebAPI2) to the ACS federation endpoint for my namespace.
Under WAAD, I've seen where I can add my own application. When I create the new application, is this creating a tenant in my directory? I dont see where I can register my Idp's and configure the Idp's for my relying party. In addition to authenticating via social networks (like facebook/google/etc), I'm going to want to write a custom Idp to hit against my on-premesis user store. Is this possible in WAAD? Finally when creating the application (tenant) in WAAD, its prompting me for a Signon URL. Isn't WAAD supposed to manage the signon, the way it did under ACS? when I defended a website via ACS, the user was redirected to the ACS sign in page, where they could choose from a list of Idp's for login. Why then, under WAAD, do I, the app developer, need to code a sign on page? I'm pretty confused about this.
WAAD does not replace ACS. WAAD is a single identity provider (IdP), whereas ACS can act as a Security Token Service (STS) for multiple IdPs, but is not itself an IdP. Think of ACS more as a broker that has taken some of the work out of integrating with some of the common identity providers out there (Facebook, Google, Yahoo, Live, etc) so that you as the application developer can code to one interface instead of multiple.
My suggestion would be to continue to use ACS as your single point of contact for federated identities and add WAAD as an additional IdP to those applications in your suite that require it. This is a pattern we follow in a number of our applications where we use ACS as the main STS and then expose one or more of the IdPs to an application depending on our needs.
As to your question about a custom IdP pointing to an on premise user store you might consider using Thinktecture Identity Server instead of rolling your own. You can expose Thinktecture Identity Server from ACS just as you would any other IdP in your suite.