Here is the way authentication is set up.
- Client Browser sends the request (URL below) to client's ADFS server,
- Client ADFS then look at the nested relay state and forward the request to our ADFS server.
- Our ADFS look at the request and send the request to our APP.
URL is here.
https://clientadfs.clientdomain.com/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3Dhttps%3A%2F%2ouradfs.ourdomain.com%2Fadfs%2Fls%2F%26RelayState%3DRPID%3Dhttps%3A%2F%2ourapp.ourdomain.com%2Fvaruna%2Fconsole%2Fsso.aspx%3FsamISso%26lang%3Den_CA
The request produces a blank page with no error on the ADFS server.
I got the fiddler trace the client. Client uses users' email address to identify the users. I can see in the SAML token sent to Client's ADFS has this email address.
This SAML token goes to our ADFS server and I see the SAML response that come out of our ADFS server. This however does not have the user email address. I think that is the problem.
On our ADFS server, I have this Client's claim (on Claims Provider Trust) to handle user ID (which is their email):
Claim Rule name: Email
Incoming Claim type: Name ID
Incoming Name ID format: Email
Outgoing Name ID format: Email
Pass through all claim values.
Here is the claim in Claim Rule Language
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] == "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"]
=> issue(Type = "Email", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);
On client's ADFS config, this is their email/Userid configuration:
IssuanceTransformRules : #RuleTemplate = "LdapClaims"
#RuleName = "Pass email"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccou
ntname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/20
05/05/identity/claims/nameidentifier"), query = ";mail;{0}", param = c.Value);
I have no idea what I am doing wrong. Can anyone spot my issue? or can you suggest where I should look at?
Thanks for your help!
RM
"to handle user ID (which is their email)"
So is the SAML assertion an assertion for a type of email or for a type of userID? i.e. what is the assertion name for this attribute.
On the ADFS side. to transform an email claim it expects a type of "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
Update
You need to transform NameId to email. NameId also has an "Incoming name ID format" which I'm guessing is "email". You need to verify this in the SAML metadata.
So your claim rule should look like:
c:[Type ==
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"]
== "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"] => issue(Type =
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value,
ValueType = c.ValueType);
Update 1
ADFS supports:
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
so the format can either be emailAddress, persistent or transient.
Try the Transform rule with all three formats and see.
Also, what claims is your application getting? You can dump them out via How to: Access Claims in an ASP.NET Page.
Related
In our current WSO2 setup, after a user performs a self creation, we place his account into a locked state, and send a confirmation email to the address specified during creation. This email has a link which allows the user to verify his account.
For development purposes, we are attempting to get the workflow down using the UserInformationRecoveryService wsdl in SOAP UI. The service which we seem to want is called sendRecoveryNotification. Here is the signature of this service:
sendRecoveryNotification(String username, String key, String notificationType)
The username parameter is simply the username of the WSO2 user in question, which we have. For the notificationType we have been using email, which presumably would trigger an email to be sent to the user. The problem is with the key parameter. It is not clear what value should be used as key, and all our guesses always lead to this error response:
18001 invalid confirmation code for user : tbiegeleisen#abc.com#tenant.com
We also noticed that several other services also expect a key, and it is not clear how to get this value.
Can someone shed light on the workflow for user recovery in WSO2? It seems to be a Catch-22 with regard of requiring a token in order to generate a new token to be sent to a user.
The WSO2 documentation clearly spells out the workflow for recovery with notification. The key which needs to be used is the return value from a call to the verifyUser() SOAP web service. This service itself expects a Captcha which normally would be sent from the UI. Here is a code snippet showing how a recovery notification can be sent:
String cookies = client.login("admin#tenant.com#tenant.com", "admin");
UserInformationRecoveryUtil userInfoutil = new UserInformationRecoveryUtil(webserviceUrl, cookies);
CaptchaInfoBean captchaInfo = new CaptchaInfoBean();
captchaInfo.setImagePath(captchaPath);
captchaInfo.setSecretKey(captchaKey);
captchaInfo.setUserAnswer(captcha);
String username = emailId + "#" + tenantDomain;
String key = userInfoutil.verifyUser(username, captchaInfo);
// now pass the key based on the Captcha along with the type of recovery action
userInfoutil.sendRecoveryNotification(username, key, "accountUnLock");
I'm trying to setup PingFederate as a claim provider in ADFS with the intention that I federate from a PF realm through ADFS to an ADFS RP. I want ADFS to add attributes from Active Directory to the assertion before sending it to the RP. PingFederate is only sending the user's Windows login ID. On the Claim Provider side I'm passing through Name ID. Just for testing, I have tried adding an attribute like this:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]
=> add(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Value = "myemail#test.com");
I added this on the CP side both above and then below my pass through rule and nothing was added to my assertion. I also tried this on the RP side with no luck.
I guess my question is whether this is possible in ADFS. Ultimately I would like PingFed to send the user's login ID as the name ID, have ADFS lookup the user in Active Directory and add the email address as a claim then send the assertion to the RP. As for adding the attribute from Active Directory, I found this post technet.microsoft.com/en-us/library/ff678048.aspx. Problem is I can't even add a manual value.
For a manual value, use something like:
=> issue(type = "http://contoso.com/partner", value = "Adatum");
For the query, use something like:
Use the normal LDAP rule to produce a loginID claim and then
c:[Type == "http://company.com/claims/loginID", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"), query = ";email;{0}", param = c.Value);
I figured this out. My first use case is to ensure that the AD account exists.
Essentially what is required are 3 claim rules on the CP side:
1 - perform the lookup based on the name ID. I created a custom rule to
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]
=> add(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"), query = "sAMAccountName={0};objectSID;{1}", param = c.Value, param = "MYDOMAI\" + c.Value);
The parameters required in for the query are:
LDAP query to locate the user
Attribute(s) to extract
User's login ID in the format DOMAIN\userid
2 - a claim rule to simply pass the name ID through
3 - a claim rule to simply pass the SID through
On the RP side, I have 2 claim rules to pass the name ID and the SID through. Then I have an Issuance Authorization Rule to ensure that the SID is present as a claim. This is a custom rules with the following:
EXISTS([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "PermitUsersWithClaim");
Seems convoluted but this is what I have. My second use case is to ensure the account is enabled, but I'm not sure if this is possible because the disabled attribute is stored as a bit in the userAccountControl attribute.
I am new to LDAP API. I am able to connect to a LDAP server and search the user. How would I authenticate a user with email/password using UnboundID LDAP API ?
I have not seen any authentication in LDAP which uses email and password to authenticate user?
Is it Possible to authenticate the user using email and password
What I am doing to authenticate the user given as below
Searching below the USERS Directory and matching Email and Finding his DN
Based on DN connecting the user and if Connection Successful, Authenticate the user or Execption occurs in Connecting then user is not Authenticated
Is there right way to authenticate the User?
You have to do two steps.
Using an administrative login, search the directory for the user.
Using that user's DN and the password he supplied, attempt to bind.
If either didn't succeed, either the identity or the password is incorrect.
Using the UnboundID LDAP SDK, this simple piece of code searches for the entry. If there is one entry that has the known email address, BIND using that DN (the password has to come from someplace else). Nothing happens (authenticated is false) is there is more one entry that matches the search parameters or if no entries match the search parameters. This code assumes that baseObject is dc=example,dc=com, subtree search is required, and the attribute with the email address has an alias mail. The code also assumes there is a bindDN and bindPassword that has sufficient access rights to search for the user with the email address. The email address for which it searches is assumed to be babs.jensen#example.com.
Exceptions are ignored throughout.
String baseObject = "dc=example,dc=com";
String bindDN = "dn-with-permission-to-search";
String bindPassword = "password-of-dn-with-permission-to-search";
// Exceptions ignored.
LDAPConnection ldapConnection =
new LDAPConnection(hostname,port,bindDN,bindPassword);
String emailAddress = "babs.jensen#example.com";
String filterText = String.format("mail=%s",emailAddress);
SearchRequest searchRequest = new SearchRequest(baseObject,
SearchScope.SUB,filterText,"1.1");
SearchResult searchResult = ldapConnection.search(searchRequest);
boolean authenticated = false;
if(searchResult.getEntryCount() == 1)
{
// There is one entry with that email address
SearchResultEntry entry = searchResult.getSearchEntries().get(0);
// Create a BIND request to authenticate. The password has
// has to come from someplace outside this code
BindRequest bindRequest =
new SimpleBindRequest(entry.getDN(),password);
ldapConnection.bind(bindRequest);
authenticated = true;
}
else if(searchResult.getEntryCount() > 1)
{
// more than one entry matches the search parameters
}
else if(searchResult.getEntryCount() == 0)
{
// no entries matched the search parameters
}
In our system, we have users registered from different domain (lets say their mail address are #gmail.com,#outlook.com,#yahoo.com). I have a requirement to restrict the user's access to RP based on the domain he comes from. For this setup, I tried to configure Issuance Authorization rule in ADFS (to allow users only from a particular domain) with the below rule
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Value =~ "gmail.com$"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");
I was passing email address claim through issuance authorization rule tab so I didn't initialized the input in the authorization ruleset as mentioned in the technet link (under Sending the execution output to the claims pipeline Section)
After the entire process has run for a give rule set (steps 1, 2, and 3), the newly issued outgoing claims (content of the output claim set) will be used as input to the next rule set in the claims pipeline. This allows for claims to flow from the output of one rule set to the input for another rule set, as shown in the following illustration.
But the authorization doesn't seem to work.
The claims configured in the first tab ( Issuance transform rules ) are not passed to the second tab (Issuance Authorization rules).
So we need to repeat the process again in the second tab (map emailaddresses -> emailaddress) as shown below.
Now the custom rule works perfectly.
If you need to add few more email domains to the acceptance criteria just use the "|" symbol:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Value =~ "yahoo.com$|gmail.com$"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");
Can you guys help me out on how to send DN in a claim from ADFS 2.0?
Thanks!
There doesn't seem to be a standard URI for DN but you can always roll your own.
The ADFS claims rules box is actually configurable - refer ADFS : Selecting claim that's not in the default drop down
So in the "LDAP Attribute" enter "DN" and in the "Outgoing Claim Type" enter something like "http://company.com/identity/claims/DistinguishedName".
Edited:
LDAP attributes see here : Selected LDAP Attributes
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"), query = "; distinguishedName;{0}", param = c.Value);