We have a SAML 2.0 federated environment (IDP and SP). I would like to generate a custom attribute for assertions created only for one SP. As such, I will not modify the IDP configuration.
The snippet of the SAML Assertion we need to create:
< saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" >
Name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:groups">
< saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
xsi:type="xsd:string">ABCD
According to SAML2 specifications, we need to modify the SP extended metadata to provide this attribute. The constant string "ABCD" is the attribute we want to send. I've modified as such, but no results. Can anyone provide insight?
< Attribute name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:groups">
< Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|ABCD</Value>
< /Attribute>
Also tried:
< Attribute name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE:groups"
nameformat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
< Value>"ABCD"</Value>
< /Attribute>
Looking at the metadata spec it seems like you use the following syntax to define what attributes you want from the IDP. Of course the IDP must be configured to allow the export of such attribute to..
<AttributeConsumingService>
<ServiceName xml:lang="en">youname</ServiceName>
<RequestedAttribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:theformat"
Name="theAttributeName"
FriendlyName="humanReadableName"/>
</AttributeConsumingService>
The spec of this is here at page 21
https://www.oasis-open.org/committees/download.php/35391/sstc-saml-metadata-errata-2.0-wd-04-diff.pdf
Related
I'm using Auth0 as an idP, my Service Provider requires that i add a custom attribute in the assertion.
I've tried doing this on the Dashboard. Dashboard > Applications > Applications -> AddOns. Following this article. https://auth0.com/docs/authenticate/protocols/saml/saml-configuration/customize-saml-assertions
I've added my_custom_attr in the mapping object, screenshot below.
However when i 'Debug', my custom attribute isn't showing in the assertion xml and my Service Provider isn't receiving the custom attribute. They're only receiving the default attributes. email, nickname etc
When using Auth0 as a SAML identity provider, you can customize the outgoing claims using mapping. Consider you have the user profile that looks like this:
RAW JSON
{
"user_id": "auth0|qwer-1234-zxcv-0987",
"email": "john.doe#example.com"
"picture": "https://placeholder.img/user",
"name": "John Doe"
}
If you need the picture attribute to be in the outgoing claims, you would do a mapping like this:
"mappings": {
"picture": "http://schemas.auth0.com/picture"
}
Note that the each property name on the left side represents a property in the Auth0 profile. Each "value" on the right side is the name for the resulting SAML attribute in the assertion.
If you don't have a my_custom_attr property in the user profile, this mapping won't work. The workaround is to use an Auth0 Rule to add that value during the user log in time. You can read more about it here.
Here's an example.
function customizeMappings(user, context, callback) {
// we are altering the user profile
user.my_custom_attr = "My Custom Attribute";
context.samlConfiguration.mappings = {
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/color": "my_custom_attr"
};
callback(null, user, context);
}
Note that using context.samlConfiguration.mappings in a Rule will override the configuration you've set in your SAML add-on. Therefore, all the mappings you set in the add-on will be lost if you're using a Rule to customize the SAML assertions.
My original post is here
I am trying to protect a set of REST endpoints with Shiro. My theory is that if I pass a JWT with my REST request, that I can use Shiro (via annotations) to secure my endpoints.
I've create my endpoints like this (for example):
#GET
#Produces(MediaType.APPLICATION_JSON)
#Path("status/{companyId}")
#RequiresAuthentication
#RequiresRoles("SomeRole")
public Response getStatus(#PathParam("companyId") int companyId){
... do stuff ...
}
I'm expecting that if I call the endpoint without authenticating, I will get a HTTP 401 error. However, the method is called successfully if the JWT is not supplied as it would be when there is no security on it at all.
I assume then that my Shiro config is incorrect. Since this is strictly a 'backend' application, I have no use for the Shiro/Stormpath configurations that apply to anything 'front-end' related (such as loginURLs, etc.)
Here is my shiro.ini :
[main]
#ERRORS IF UNCOMMENTED
#cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
#securityManager.cacheManager = $cacheManager
#stormpathClient.cacheManager = $cacheManager
# NOT NEEDED?
#sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
#securityManager.sessionManager = $sessionManager
#securityManager.sessionManager.sessionIdCookieEnabled = false
#securityManager.sessionManager.sessionIdUrlRewritingEnabled = false
[urls]
/** = rest
This configuration lets every request through (as described above).
If I uncomment the [main] section, I get IllegalArgumentException: Configuration error. Specified object [stormpathClient] with property [cacheManager] without first defining that object's class. Please first specify the class property first, e.g. myObject = fully_qualified_class_name and then define additional properties.
What I need to figure out is what is the correct minimum Shiro configuration for REST endpoints (and ONLY REST endpoints) so I can allow access with a JWT.
Thanks for any help.
I'm guessing the annotations are not being processed by anything at runtime. You will need to tell your JAX-RS app to process them.
I've done this with this lib in the past:
https://github.com/silb/shiro-jersey/
Specifically something like this:
https://github.com/silb/shiro-jersey/blob/master/src/main/java/org/secnod/shiro/jersey/AuthorizationFilterFeature.java
As for the second part of the problem, my only guess is Stormpath/Shiro environment is not setup correctly.
Did you put filter config in your web.xml or is all of the config loaded from the servlet fragment?
I'm having trouble getting ADFS to send claim to my app. The authentication is now completing successfully, but none of the claims we've set in rules are being sent with the response. I have two rules in this order.
In the first rule, my understanding is the types section is whatever my application is expecting ADFS to output, and doesn't need to correspond to LDAP values. What is really important is the query which must reference valid LDAP attributes. I am sure the query values are valid LDAP attributes, as another working Relying Party configuration uses these same query values(but they use different values in types for output).
In the second rule, I am referencing Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier". This is not a type in LDAP, but is a reference to the claim created in the first rule. Am I doing that correctly? Can the second rule reference an output type from the first rule?
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/givenname",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"),
query = ";givenName,sn,mail,employeeI;{0}", param = c.Value);
Second rule
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType,
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://somedomain.com/adfs/services/trust",
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "https://someapp.somedomain.com/sp");
Also, is there any reason ADFS wouldn't send claims if the Relying Party is not setup with a certificate for encryption(it is using the IDP certificate to generate signatures/validate)?
The usual reason claims are not sent is that those AD attributes are null.
You can't use the same claim as input / output.
Take nameidentifier out of the first claim, have a separate claim which outputs something like http://company.com/temp and which is an add not an issue.
Then use http://company.com/temp as input to the second claim with output http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier.
When I create a resource/method in AWS API Gateway API I can create one of the following methods: DELETE, GET, HEAD, OPTIONS, PATCH or POST.
If I choose GET then API Gateway doesn't pass authentication details; but for POST it does.
For GET should I be adding the cognito credentials to the URL of my GET? or just never use GET and use POST for all authenticated calls?
My set-up in API Gateway/Lambda:
I created a Resource and two methods: GET and POST
Under Authorization Settings I set Authorization to AWS_AIM
For this example there is no Request Model
Under Method Execution I set Integration type to Lambda Function and I check Invoke with caller credentials (I also set Lambda Region and Lambda Function)
I leave Credentials cache unchecked.
For Body Mapping Templates, I set Content-Type to `application/json' and the Mapping Template to
{ "identity" : "$input.params('identity')"}
In my Python Lambda function:
def lambda_handler(event, context):
print context.identity
print context.identity.cognito_identity_id
return True
Running the Python function:
For the GET context.identity is None
For the POST context.identity has a value and context.identity.cognito_identity_id has the correct value.
As mentioned in comments: all HTTP methods support authentication. If the method is configured to require authentication, authentication results should be included in the context for you to access via mapping templates to pass down stream as contextual information.
If this is not working for you, please update your question to reflect:
How your API methods are configured.
What your mapping template is.
What results you see in testing.
UPDATE
The code in your lambda function is checking the context of the Lambda function, not the value from API Gateway. To access the value passed in from API Gateway, you would need to use event.identity not context.identity.
This would only half solve your problem as you are not using the correct value to access the identity in API gateway. That would be $context.identity.cognitoIdentityId (assuming you are using Amazon Cognito auth). Please see the mapping template reference for a full guide of supported variables.
Finally, you may want to consider using the template referenced in this question.
I came to know that in any SSO Solution if SP needs any additional attributes it can publish them in its metadata using AttributeConsumingService argument. The required attributes can now be added like as below:
<md:AttributeConsumingService index="0"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<md:ServiceName xml:lang="en">ABC</md:ServiceName>
<md:ServiceDescription xml:lang="en">ABC</md:ServiceDescription>
<md:RequestedAttribute isRequired="true"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:2.5.4.42"
FriendlyName="FirstName"/>
</md:AttributeConsumingService>
Now, if I want to add a custom attribute in my SP metadata, lets say "Role" of a user, how should I add it in the metadata? I mean, what would be its Name(this is what I'm unable to find!), NameFormat(is it urn:oasis:names:tc:SAML:2.0:attrname-format:uri?) and FriendlyName(can I give it as "Role" here?). I've not found anything related to this in the SAML2Core document.
Any suggestions please!
Thanks,
Abhilash
There is no universal answer as it depends on which IDP/federation you use and what is supported by it.
Generally, the friendly name is just a human-readable identifier for the attribute and the value can be freely defined.
The NameFormat and Name are defined based on Attribute Profile used by your IDP (e.g. Basic profile, X.500/LDAP Profile, ...). The expected values can be found in SAML 2.0 profiles document chapter 8.
You can find an example of how this is employed in practice for e.g. inCommon federation in their documentation.