I have a question regarding claim rules and how they are processed in ADFS. As per my understanding after reading [this] (https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-the-claims-engine) there are three parts of claim rules execution - Initialisation (Input claims set is created and the input claims are placed here), execution of conditions and rules in a claim rule, and issuance of claims to a relying party. What I am trying to understand is if there is only default claims trust provider, i.e. AD and a user logs in trying to do IdP Initiated SAML, then at the initial phase, is the input claim set populated with all the attributes of a user in AD? Before the execution process starts, who or what decides that what will be present in the input claims?
At logon time the claims rules on the claims provider (AD in your case) decide what's available in the pipeline. Not all user attributes populated in AD for the user are read. E.g. if mobile is populated it wont be read and mapped to some claim.
So after credentials are validated the AcceptanceTransformRules on the claims
After logon IssuanceAuthorizationRules are used to decide whether to issue claims or not. Assuming you get past this stage with at least one permit and zero deny, then you move to the issuance transform rules processing stage on the relying party.
When the issuancetransformrules defined on the relying party are executed and you choose to issue a claim that uses an AD attribute such as mobile, you can choose to issue a claim like http://myorg.com/mobile with the mobile attribute value. The LDAP queries to use the AD attribute store are used at this point. You can also choose to use incoming claims added at logon time as input at this stage to decide what to add/issue to the pipeline.
Once all the issuancetransformrules are processed, based on what you choose to explicitly pass through claims added to the pipeline at the claims provider trust level may or may not be sent to the relying party.
Use https://adfshelp.microsoft.com/ClaimsXray/TokenRequest to play with different combinations of rules on the CP and RP trust levels to further your understanding.
Related
I'm integrating with a 3rd party and for the claims configuration, they recommended we create sAM-Account-Name to Name ID, and keep getting this error in the SAML response:
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy" />
</samlp:StatusCode>
</samlp:Status>
So I assumed I was not sending the correctly formatted NameID. In the SP's metatdata, they have this listed:
<NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
</NameIDFormat>
Rightly so, I assume I'm supposed to use the transient NameID format. However, that doesn't work either, and the vendor insists they expect our SAML response to use urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified as the Name ID format. From what I understand, that's default for ADFS.
As a test, I followed the steps here: https://blogs.msdn.microsoft.com/card/2010/02/17/name-identifiers-in-saml-assertions/ and was able to get a bogus NameID (transient) to pass to the vendor's site, where it then displayed back in the browser that the username was not valid, so at least I got something which makes me believe I'm on the right track and their authentication server is expecting transient while their application is not.
I would try the steps here, but I don't want to affect my whole claims provider: https://social.technet.microsoft.com/wiki/contents/articles/4038.ad-fs-2-0-how-to-request-a-specific-name-id-format-from-a-claims-provider-cp-during-saml-2-0-single-sign-on-sso.aspx
We're running Server 2012 R2 for our ADFS server. This isn't the first Relaying Party Trust we've configured, and our setup is working well with our other vendors. I however, am relatively new to managing ADFS, so I may have missed something simple.
Any thoughts or guidance would be appreciated.
If the claims mapping in ADFS for your relying party includes Active Directory samAccountName to SAML NameID, the "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" specified by the service provider's metadata doesn't really make a lot of sense as this value isn't transient.
As per the SAML v2.0 specification, the optional NameIDPolicy in the SAML authn request "specifies constraints on the name identifier to be used to represent the requested subject".
In practice, it's simpler to either not include a NameIDPolicy so it defaults to "urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" or explicitly use this value.
Given the above, the NameIDFormat in the service provider's metadata can be safely ignored and NameIDPolicy not included in the authn request.
The the SP can deny a claim based on its format, which is ultimately the issue. The solution then is the SP should either change their requirements, or one must send the claim in the required format.
In this case, the SP is requiring the claim to be transient, even though they verbally require unspecified (default). Verbal claim requirements don't count when dealing with systems!
To get ADFS configured with this SP, one simply needs to:
Create a transform rule, with the rule template: Send LDAP Attributes as Claims
LDAP attribute is SAM-Account-Name
Outgoing Claim Type is whatever you want it to be (custom text, not from the dropdown)
Create another transform rule with the rule template: Transform an Incoming Claim
The incoming claim type is whatever your Outgoing Claim Type was previous.
The Outgoing claim type is then Name ID with the format as Transient Identifier.
This will allow the sAM-Account-Name to be sent to the SP with a transient format, even though we know that attribute is by definition, not transient.
See screenshots:
We have an existing web application which works with its own users, stored in a local SQL server database and each user has specific rights to access specific content.
A new customer is interested in using this application, but their requirement was that it should have SAML 2.0 integrated.
Now, I'm new to SSO, but I assume they want this so all user management is done at their place and that their users can log on at any of their services, using the same credentials.
The user rights defined at our web application however, are application specific; they have no meaning outside our application. So I assume these fields should remain stored and managed at our end, instead of managed at the identity provider?
But what would be the best way initiate this? I could create an empty user record locally whenever the user logons for first time, but he would literally not be able to do anything without proper rights. I could give him default right settings, but there should be at least 1 administrator to distribute the rights of the remaining users. Is it common to ask additional fields at the identity provider to initiate users for a specific service?
This can be done using entitlements sent in a SAML2 attribute. e.g. if you have a normal user profile for your application, you can ask the IdP to release an attribute such as eduPersonEntitlement or urn:oid:1.3.6.1.4.1.5923.1.1.1.7 as it's known in SAML2. If the IdP owner agrees to release this attribute you can agree a controlled vocabulary with them for the value of the attribute.
So when a normal user logs in to your application using SAML2 and their attributes arrive in an AttributeStatement with a collection of SAML2 Attribute instances you can look for urn:oid:1.3.6.1.4.1.5923.1.1.1.7. If it has a value of, perhaps, https://yourapp.com/entitlement/user you can set them up with a normal user account. If they have a value of, perhaps, https://yourapp.com/entitlement/admin, you can set them up with admin rights.
Just be careful to compare what they already have (if anything) with their incoming SAML2 entitlement, in case they longer are an admin. The IdP decides who is a normal user and who is an admin but that's up to them to work that out. All you care about is the value of urn:oid:1.3.6.1.4.1.5923.1.1.1.7
The full set of eduPerson attributes is here
I'm working on setting up a service provider that supports SAML. I've added two identity providers - one custom one that I built from SimpleSAMLphp and then ssocircle. So I log in to the selected identity provider, and then it returns to my service provider and I inspect the attributes of the SAML Auth object. The identity provider I built returns whatever I want it to (obviously). The ssocircle one only returns e-mail, first, and last names.
So now to map this to the user of the service provider, I have to use some value the identity provider provides. So this led me to wonder how it should be done. Since ssocircle only gives me e-mail as a useful value, do I just use the e-mail to map to the SP user?
Let's pretend for a second that ssocircle doesn't validate e-mail addresses. So now if I create a second account at ssocircle with the same e-mail, I can log in as my coworker who I know has admin privileges.
So my question is, do I handle this? Or is the onus on the admin who set up the identity provider and say "well you shouldn't have used an identity provider that doesn't validate e-mail addresses!" or something of that nature? Or should I only allow identity providers that pass a certain value, like userid or 0.9.2342.19200300.100.1.1? Is there something that identity providers commonly use?
Well, you said it, two different identity providers. They both should be passing not only the email but different entity ids and certificates.
In multi-tenant applications that would mean two different applications, but if you plan to allow multiple IDPs to point to a single app you will need to ensure that same email but different entityID create two different users and or throw an error after the first was created that the second cannot be provision nor access.
Interesting question. These days people think always of auto federation of users by some attribute. In early SAML federation days federating two unrelated users was a manual step in which a user logs in at the IDP and logs in to the SP providing both sets of credentials and then manually federated these two user accounts. The process guarantees that only the user who has access to the accounts at the IDP and SP controls the linkage between the two. It also allows anonymous naming identifiers (SAML persistent NameIDFormat) which protects privacy because even the IDP does not know the user name at the SP and vice versa.
Unfortunately the process was to complicated for users and with the success of OpenID the aspect was getting less and less important.
To answer your question: What you describe happens in the real world -see Office 365 authentication bypass
You need to check that the IDP is authoritative to send a specific attribute and attribute scope in case of two IDPs.
In case of one IDP the attribute must be verified (SSOCircle verifies email address) and it should better be unique (For example SSOCircle userId) to avoid that two users with the same attribute are mapped to a single user at the SP.
If the userid's are not the same (e.g. you use a simple user ID at the IDP and email address format at the SP) you can still add a correlation attribute at the SP (e.g. an attribute named ssocircle-userid) and use that to link the user accounts.
I was told that it is possible to give information about group membership during a SAML authentication request. We have to connect to an application that does use SAML (we are at the end that is creating the SAML answer XML). Authenticating a user works fine but I can't find a way to specify a "member of" or similar attribute.
Can you explain to me how to pass group memberships in SAML during authentication or have an example ?
I know there is a possibility to take care of authorization in SAML at a socalled Policy Decision Point. But this would mean that a SAML flow would happen for each or some (if batched) entities we want to check authorization for.
Let me give you an example what we are trying to do. This example is made up but shows the problem we want to solve.
Let's assume you have a hard drive with lots of directories and files on it. We use SAML to authenticate the person that tries to access that drive. Members of the group "admin" are allowed to read and write and members of group "user" are only given read permission.
Because of this we want to send the group memberships of a user when he or she authenticates. Because otherwise it would mean that the application has to check for every file if the user is in the necessary group. If it was clear from the beginning (after authentication took place) that someone is a member of a specific group the application can cache that in memory.
As with most things in SAML, this depends on the identity provider as well as the application.
Many identity providers have access control to allow or deny specific users or groups to access an application. Sign-on is then denied by the IdP after authentication based on the ID of the application (from the SAML request) and access control configured in the IdP. If you just want to control who has access to the application, then this is all you need, and most, if not all, identity providers should have you covered.
Sometimes you also want different users or groups to have different permissions inside the application, or you want memberships in certain groups on the IdP to be mapped to membership in groups inside the app's own user and group database (or other application-specific group-like concepts). There is no standard for this, but some identity providers allow the definition of attribute mapping rules based on group membership. For example, in ADFS, you can create a claim rule that sets a specific SAML attribute to a specific value if and only if the user is a member of a specific group in AD. You would then set up such a rule and set a SAML attribute that your application understands to a value it understands.
Alternatively, if an application supports configuration of multiple IdPs, then you can configure one app / IdP mapping per group, and for each group add an attribute mapping rule with a hard-coded group name in an attribute that your application understands.
I currently have two relying parties (RP) configured on my adfs 2.0 server. I also have two claims provider trusts. I simply want to restrict access to the first RP if the user belongs to claims provider 1.
Is there a claim rule I can put that would let me inspect the user's issuer and then grant access or not?
I'm also wondering if this behavior is even acceptable in a SSO infrastructure. Should I deploy two instances of ADFS 2.0 in order to support this (one trusts claims provider 1 while the other doesn't).
Thanks for any ideas or design inputs.
I don't know if this is a good idea, but this should work:
Add a custom rule to the claims provider you want to deny with content like this:
=> issue(Type = "http://schemas.YOURDOMAINHERE/claims/AccessRP_X", Value = "Deny");
Then on the RP, edit claim rules,
choose Issuance authorization rules,
Add Rule.
In the dialog, use
template "Permit or Deny Users based
on an Incoming Claim".
For incoming
claim type, use the same type as in
the custom rule.
In incoming claim
value, write Deny
And Choose the
radio button "Deny access to users
with this incoming claim".
Press finish
Hope this works for you.