We have several service providers using Saml 2.0 for single sign-on and they are all working fine. Our most recent addition is balking because we send a NotBefore attribute on the SubjectConfirmationData element. As far as I can tell, this is part of the xsd schema for Saml 2.0 (https://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd) but then it is marked as MUST NOT in this profiles PDF (https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf).
What am I missing?
As you figured out, the Web Browser SSO profile - which is the one you are using to provide single sign on for your users as an Identity Provider - dictates that you should not set NotBefore. The profile sets further limitations to the schema defined for Assertion to be used generically, which is totally fine.
The service provider at hand strictly checks compliance and thus rejects your Assertion. The fact that it has been working so far probably means that the other service provider implementations were more lenient.
Related
I would like to build SAML request in such a way that it support both Windows based Authentication and Form Based Authentication.
Scenario 1
ADFS Authentication policies are set to Windows based Authentication and Form Based Authentication.
If both authentications are set first priority should be given to Windows based Authentication.
Scenario 2
ADFS Authentication policy is set to Form Based Authentication.
In this case Form based authentication should be done.
My Question is how to set RequestedAuthnContext in SAML AuthnRequest so that above scenarios are covered.
Which Comparison Type should be used (MINIMUM,EXACT,MAXIMUM,BETTER)?
This is code snippet
RequestedAuthnContext requestedAuthnContext = SAMLUtils.buildSAMLObject(RequestedAuthnContext.class);
requestedAuthnContext.setComparison(AuthnContextComparisonTypeEnumeration.MINIMUM);
AuthnContextClassRef windowsAuthnContextClassRef = SAMLUtils.buildSAMLObject(AuthnContextClassRef.class);
windowsAuthnContextClassRef.setAuthnContextClassRef("urn:federation:authentication:windows");
AuthnContextClassRef passwordAuthnContextClassRef = SAMLUtils.buildSAMLObject(AuthnContextClassRef.class);
passwordAuthnContextClassRef.setAuthnContextClassRef(AuthnContext.PPT_AUTHN_CTX);
requestedAuthnContext.getAuthnContextClassRefs().add(windowsAuthnContextClassRef);
requestedAuthnContext.getAuthnContextClassRefs().add(passwordAuthnContextClassRef);
My Question is how to set RequestedAuthnContext in SAML AuthnRequest so that above scenarios are covered.
I tried all Comparison Types. But Expected scenarios are not working.
The SAML spec (Core with errata, section 3.3.2.2.1) says this about RequestedAuthnContext element:
If ordering is relevant to the evaluation of the
request, then the set of supplied references MUST be evaluated as an
ordered set, where the first element is the most preferred
authentication context class or declaration. For example, ordering is
significant when using this element in an AuthnRequest message but
not in an AuthnQuery message.
The part about evaluation as an ordered set was clarified in the errata revision of the spec
The comparison rules:
If Comparison is set to "exact" or omitted, then the resulting
authentication context in the authentication statement MUST be the
exact match of at least one of the authentication contexts specified.
If Comparison is set to "minimum", then the resulting authentication
context in the authentication statement MUST be at least as strong (as
deemed by the responder) as one of the authentication contexts
specified.
If Comparison is set to "better", then the resulting authentication
context in the authentication statement MUST be stronger (as deemed by
the responder) than any one of the authentication contexts specified.
If Comparison is set to "maximum", then the resulting authentication
context in the authentication statement MUST be as strong as possible
(as deemed by the responder) without exceeding the strength of at
least one of the authentication contexts specified.
Our translation of your scenario:
Windows auth should take precedence over form-based auth
Form-based auth should be the fallback
The most spec-compliant way of implementing the request is
requestedAuthnContext.setComparison(AuthnContextComparisonTypeEnumeration.EXACT);
...
requestedAuthnContext.getAuthnContextClassRefs().add(windowsAuthnContextClassRef);
requestedAuthnContext.getAuthnContextClassRefs().add(passwordAuthnContextClassRef);
If your ADFS policy has Windows auth and Form-based auth as selected options, the IdP should select Windows-based auth since it's referenced first in the authentication request. If your ADFS policy contains only Form-based auth, the IdP should go with that since it still exactly matches one of the two auth contexts in your authentication request.
If you did NOT have control over ADFS setup and you could not guarantee the auth options chosen in ADFS policy, then a safer implementation would be to use Minimum as the comparison strength:
requestedAuthnContext.setComparison(AuthnContextComparisonTypeEnumeration.MINIMUM);
...
requestedAuthnContext.getAuthnContextClassRefs().add(windowsAuthnContextClassRef);
requestedAuthnContext.getAuthnContextClassRefs().add(passwordAuthnContextClassRef);
So far we've talked about the spec perspective but does ADFS respect the spec and implement it correctly? ADFS 2.0 claims to do so with a short list of supported auth contexts. On ADFS 3.0 there's at least one report of this feature being broken (allegedly). Verification of this scenario on ADFS 4.0 and 5.0 would be an interesting bullet point, perhaps someone can comment.
First of all, the Authentication Context is an abstraction.
Which actual Authentication mechanism is really used by the IdP is totally up to the IdP.
Even if you request 'SPNEGO Kerberos' ("urn:federation:authentication:windows") the IdP may use a totally different mechanism.
Furthermore there is no specification that defines an order upon Authentication Context Class Refs ... again it's up to the IdP implementation to decide which mechanism it considers stronger than another.
From that respect you may use 'MINIMUM' as comparison. 'EXACT' may reduce the probability for successful SSO flow.
We're currently using IdentityServer 4 as our SSO.
As part of a requirement set by our PM, an endpoint for email validation is required. Such endpoint would provide a simple functionality: validate the existence of an already registered email in our system.
This raised the concern about directory harvest attack, increasing the attack surface, etc.
Since IdentityServer does not provide such functionality out of the box, we believe for good reasons, would it be wise to add such functionality on top of the existing one (given previously mentioned concerns) or at all in the platform?
An argument that was raised was the fact that the registration form could provide identical functionality. But, server side rendered pages, making use of anti-forgery token mitigate (eliminate?) such option it appears.
In our case, the client application is Angular2 based.
Suggestions?
When working on an Apache Tomcat SAML 2.0 based single-sign-on (SSO), I came across the property named 'IsPassive' under SAML 2.0 Authentication Requests. The SAML 2.0 spec introduces this as follows:
IsPassive [Optional] A Boolean value. If "true", the identity provider
and the user agent itself MUST NOT visibly take control of the user
interface from the requester and interact with the presenter in a
noticeable fashion. If a value is not provided, the default is
"false".
What is the most accurate meaning or example of this definition in terms of a single-sign-on scenario? Does this property have a connection with active and passive profiles in single-sign-on?
First, this has nothing to do with the Active or Passive SSO. Typically "Active" refers to Web Services based SSO (I usually think about desktop client apps for this) while "Passive" more typically refers to Browser-based SSO.
Second, by sending IsPassive=True, the SP is essentially telling the IDP, "Authenticate this user only if you can do it without have the user involved." I think the most common methods for Web SSO might be Kerberos (Integrate Windows Auth) or x509. Alternatively, if the IDP has already authenticated the user and the user has a valid session that can be re-used for the given SP AuthnRequest, then that qualifies as meeting the IsPassive=true requirements IIRC.
I hope the following question makes sense:
I manage my users in ActiveDirectory.
I authenticate them via IdentityServer3.
I authorize the APIs via the AD groups that the user is in (acting as security roles).
How should I set up IdentityServer3:
Must I use my own custom UserService to access ActiveDirectory?
and does that replace the MembershipReboot / AspNetIdentity support (or am I misunderstanding what the UserService is)?
Or should I use one of the MembershipReboot / AspNetIdentity packages from IdentityServer3, and somehow customize them to map to ActiveDirectory (and if so, how)?
Seems there is no "mapping" and should not be a mapping from AD to a membership-reboot or an aspidentity or the newer identity-reboot user stores. The reason seems to be simple: mr and aspid or ir are all ways to store the user information in a persistent way (some sort of database or repository), which is already done in AD.
The userservice is enough. It causes the ASP Identity objects to be populated, and the middleware to work as expected, calling user authentication, and user or resource authorization correctly and automatically, after the client calls are "decorated" with "Authorize" attributes or after returning from the OP (the OpenID-Connect Provider) or from separate authorization or resource providers, in security calls.
Answer update: Now in IdentityServer4 the UserService has been deprecated and instead you use IResourceOwnerPasswordValidator.
See here for working code and a detailed explanation, in the answer after the accepted one (vote it up please)
IdentityServer4 register UserService and get users from database in asp.net core
I am just getting started with SAML. AFAIK, in the authentication step, there is no direct communication between the IdP and the SP and the assertion happens via the browser.
In my applications (which will be the SP), I would like to store some user specific data (stuff like page size, other UI preferences). When the user is deleted from the IdP, I would like to purge this data from my application as well ? Is it possible to get this "event" from the IdP to the SP for such tasks ?
PS - My app is PHP based and I am likely to simplesamlphp.
Thanks,
~preetham
There is no support in the SAML 2.0 spec for having the Identity Provider call out to the Service Provider for events related to user provisioning or deactivation.
However, there is a SAML protocol called SubjectQuery and a request called NameIDMappingRequest which might serve the purpose if you had a nightly batch job or something that would query users which haven't logged on in x days to see if they still exist on the Idp.
You can find the details on these in the Profiles Section of the SAML spec but I don't know what support (if any) simplesamlphp has for these profiles.