I'm trying to connect a SAML capable App as SP to Mircrosoft Azure and Centrify as IDP. SSO (Single Sign On) works as it should but i have some problems to accomplish a complete Single Logout Process.
When the user clicks on the logout button inside of the SP a (valid) logout request is sent to the IDP. The IDP session is terminated as expected but the browser is not redirected to the SP to complete the logout process. It seems as the LogoutResponse is completely missing.
UPDATE regarding Centrify
As Nick Gamb from Centrify stated (see his answer below) at this moment Centrify does not support this feature but will implement it in the future.
UPDATE regarding Azure
You have to provide a 'wreply' parameter - containing the url_ecoded URL of the site the user should be redirected to after logout - with the logout request:
https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0&wreply=https%3A%2F%2Fmyapp.landingpage.com%2F&SAMLRequest=...
If you are using the Onelogin PHP Toolkit, then you also have to enable the 'retrieveParametersFromServer'-Setting, otherwise the logout response will always end up with a 'Signature validation failed. Logout Request rejected' error.
Following the SAML requests/responses (i have allowed myself to strip out the certificate information ...):
Centrify // Login Request
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="ONELOGIN_17b5cbaaa30c8a9edca9935a320b0de3a4088fcc"
Version="2.0"
ProviderName="MYAPP"
IssueInstant="2017-01-27T12:08:52Z"
Destination="https://aap1234.my.centrify.com/applogin/appKey/1234567-1234-1234-1234-123456789/customerId/ABC0123"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="https://myapp.com/acs"
>
<saml:Issuer>https://myapp.com/metadata</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
AllowCreate="true"
/>
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
Centrify // Login Response
<saml2p:Response ID="_7367bcc4-f4a1-4bf0-b845-ecaf0e7d6b86"
InResponseTo="ONELOGIN_17b5cbaaa30c8a9edca9935a320b0de3a4088fcc"
Version="2.0"
IssueInstant="2017-01-27T12:08:53.978Z"
Destination="https://myapp.com/acs"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
>
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://aap1234.my.centrify.com/1234567-1234-1234-1234-123456789</Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="#_7367bcc4-f4a1-4bf0-b845-ecaf0e7d6b86">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>EpN1bP9vKhLUUpyr0Hfnb3lM6gA=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</saml2p:Status>
<Assertion Version="2.0"
ID="_71ccde7d-6a7b-4b79-a6ed-1f8465b7a835"
IssueInstant="2017-01-27T12:08:53.869Z"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
>
<Issuer>https://aap1234.my.centrify.com/1234567-1234-1234-1234-123456789</Issuer>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">centrify#myapp.com</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2017-01-27T13:08:53.869Z"
Recipient="https://myapp.com/acs"
InResponseTo="ONELOGIN_17b5cbaaa30c8a9edca9935a320b0de3a4088fcc"
/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2017-01-27T12:05:53.869Z"
NotOnOrAfter="2017-01-27T13:08:53.869Z"
>
<AudienceRestriction>
<Audience>https://myapp.com/metadata</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2017-01-27T12:08:53.869Z"
SessionIndex="_71ccde7d-6a7b-4b79-a6ed-1f8465b7a835"
>
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
<AttributeStatement>
<Attribute Name="firstname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>
<AttributeValue>Firstname</AttributeValue>
</Attribute>
<Attribute Name="lastname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>
<AttributeValue>Lastname</AttributeValue>
</Attribute>
<Attribute Name="emailaddress"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>
<AttributeValue>centrify#myapp.com</AttributeValue>
</Attribute>
<Attribute Name="groups"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>
<AttributeValue>group1,group2</AttributeValue>
</Attribute>
</AttributeStatement>
</Assertion>
Centrify // Logout Request
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="ONELOGIN_dc16bcf1e9a5de948d336fbca93d4a5718b56f3d"
Version="2.0"
IssueInstant="2017-01-27T12:10:12Z"
Destination="https://aap1234.my.centrify.com/applogout"
>
<saml:Issuer>https://myapp.com/metadata</saml:Issuer>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">centrify#myapp.com</saml:NameID>
<samlp:SessionIndex>_71ccde7d-6a7b-4b79-a6ed-1f8465b7a835</samlp:SessionIndex>
Microsoft Azure // Login Request
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="ONELOGIN_40becfa9c4dc2697c9778b7b598399fbc55cef98"
Version="2.0"
ProviderName="MYAPP"
IssueInstant="2017-01-27T12:31:26Z"
Destination="https://login.microsoftonline.com/1234567-1234-1234-1234-123456789/saml2"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="https://myapp.com/acs"
>
<saml:Issuer>https://myapp.com/metadata</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
AllowCreate="true"
/>
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
Microsoft Azure // Login Response
<samlp:Response ID="_4221c6ce-51b5-48df-b33e-5c601bbc22ad"
Version="2.0"
IssueInstant="2017-01-27T12:31:27.170Z"
Destination="https://myapp.com/acs"
InResponseTo="ONELOGIN_40becfa9c4dc2697c9778b7b598399fbc55cef98"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/1234567-1234-1234-1234-123456789/</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="_ad52e38a-5f8f-4a60-9b3b-d904afd9b82e"
IssueInstant="2017-01-27T12:31:27.170Z"
Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
>
<Issuer>https://sts.windows.net/1234567-1234-1234-1234-123456789/</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#_ad52e38a-5f8f-4a60-9b3b-d904afd9b82e">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>mv1wKPg7iHLzZ5cNnu8oYX0/YvZqGsxKHsUc0umZVYw=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>...</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>...</X509Certificate>
</X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">jMPrg5XmAUzfnoCKSAXJGJMDZ8Hdj_bRU2YY6-Ozugg</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="ONELOGIN_40becfa9c4dc2697c9778b7b598399fbc55cef98"
NotOnOrAfter="2017-01-27T12:36:27.170Z"
Recipient="https://myapp.com/acs"
/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2017-01-27T12:26:27.154Z"
NotOnOrAfter="2017-01-27T13:26:27.154Z"
>
<AudienceRestriction>
<Audience>https://myapp.com/metadata</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
<AttributeValue>1234567-1234-1234-1234-123456789</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
<AttributeValue>12345-123-123-1234-12345678</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
<AttributeValue>live.com</AttributeValue>
</Attribute>
<Attribute Name="firstname">
<AttributeValue>Firstname</AttributeValue>
</Attribute>
<Attribute Name="lastname">
<AttributeValue>Lastname</AttributeValue>
</Attribute>
<Attribute Name="emailaddress">
<AttributeValue>mail#myapp.com</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2017-01-27T11:09:28.000Z"
SessionIndex="_ad52e38a-5f8f-4a60-9b3b-d904afd9b82e"
>
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
Microsoft Azure // Logout Request
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="ONELOGIN_a90edfe3da4eb07dd1e2a52df7d4cb5385cbd6c8"
Version="2.0"
IssueInstant="2017-01-27T12:32:05Z"
Destination="https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0"
>
<saml:Issuer>https://myapp.com/metadata</saml:Issuer>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">jMPrg5XmAUzfnoCKSAXJGJMDZ8Hdj_bRU2YY6-Ozugg</saml:NameID>
<samlp:SessionIndex>_ad52e38a-5f8f-4a60-9b3b-d904afd9b82e</samlp:SessionIndex>
The signout request is sent with additional GET parameters:
RelayState <= pointing to the Single Logout URL of the SP
wa <= set to „wsignout1.0“
I tested the SP configuration against a third IDP (Onelogin) and here the SP initiated logout works as expected. The user is logged out of the IDP session and then redirected with a LogoutResponse to the SP. The only difference here is that i'm able to set the SP Logout URL explicitly in the Onelogin App configuration.
Is there any option to define the SP logout url inside Azure or Centrify?
Am i missing anything?
Thanks!
As already mentioned in my updated question:
If you are using Centrify
As Nick Gamb from Centrify stated (see his answer above) at this moment Centrify does not support this feature but will implement it in the future.
If you are using Microsoft Azure
You have to provide a 'wreply' parameter - containing the url_ecoded URL of the site the user should be redirected to after logout - with the logout request: https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0&wreply=https%3A%2F%2Fmyapp.landingpage.com%2F&SAMLRequest=...
If you are using the Onelogin PHP Toolkit, then you also have to enable the 'retrieveParametersFromServer'-Setting, otherwise the logout response will always end up with a 'Signature validation failed. Logout Request rejected' error.
Thank you for submitting your question. This has been a common question as of late. The short answer is that Centrify does not support SAML single sign out at this time. The logout URL from the SAML app in Centrify is simply a logout request to the IDP. The user is always just redirected to the Centrify login page after. There is no SAML support in it thus no response.
The good news is that this feature is currently being addressed and should be released in a future build of the product to full SAML spec. Until that time, I have a possible solution for you to consider.
If you have the ability to modify your web application, specifically how it makes the logout call, you can set the logic up to make the logout call to the logout URL as an API call rather than a redirect. You will need to make the call to the logout URL from the sites Javascript so that the users session cookie is passed in the API call, as apposed to making it from server code. In doing this, you log the user out of Centrify but then you can redirect them to any page that you wish them to end up on (i.e. your web applications sign in page). The call does not require any JSON. Simply have a web request make the call to the logout url and then redirect the user to your login page.
Please feel free to follow up with me at devsupport#centrify.com and I will be happy to assist you further. I am also happy to have a call to discuss this in more detail.
Thank you,
Nick Gamb
Developer Advocate
Centrify
Related
Firstly, I created a Spring Boot project on IntelliJ basen on [blog]:https://www.javadevjournal.com/spring-boot/spring-boot-application-intellij/. Then, I generated a controller and service with #PostMapping inside of it. I used balana [github]:https://github.com/wso2/balana to implement XACML engine.
When[blog]:https://docs.wso2.com/display/IS570/Writing+XACML+3+Policies+in+WSO2+Identity+Server+-+7 is followed, a policy and xacml request created as hardcoded. When the service is called via Postman as http post (http://localhost:8080/evaluate), xacml response worked as excepted with PERMIT and DENY decisions. Everything is okey up to here.
When I want to publish it into azure web app, response includes NotApplicable as decision. Is there any anomaly into my policy and request or did I miss something?
Sample Policy
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="2" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">
<Description>sample policy</Description>
<Target></Target>
<Rule Effect="Permit" RuleId="primary-group-customer-rule">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/echo/</AttributeValue>
<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"> </AttributeDesignator>
</Match>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"></AttributeDesignator>
</Match>
</AllOf>
</AnyOf>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-subset">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin</AttributeValue>
</Apply>
<AttributeDesignator AttributeId="group" Category="urn:oasis:names:tc:xacml:3.0:group" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"></AttributeDesignator>
</Apply>
</Condition>
</Rule>
<Rule Effect="Deny" RuleId="deny-rule"></Rule>
</Policy>
Sample XACML Request
<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision="false" ReturnPolicyIdList="false">
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/echo/</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:group">
<Attribute AttributeId="group" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin</AttributeValue>
</Attribute>
</Attributes>
</Request>
Response on Localhost
<Response xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
<Result>
<Decision>Permit</Decision>
<Status><StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/></Status>
</Result>
</Response>
Response on Azure Web App
<Response xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
<Result>
<Decision>NotApplicable</Decision>
<Status><StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/></Status>
</Result>
</Response>
There should be no difference in terms of decision making (PERMIT or DENY) based on where your application is deployed.
I can tell you how to determine whether or not the issue is with your application, your policy, or an error in your request.
First, just to verify the requests are the same, have you checked the logs for the PDP on both Azure and your localhost to make sure the requests are indeed coming up the same?
If so, next I suggest you set up a very, very simple rule that will return DENY no matter what. Then ensure that you get DENY on locally running the Spring Boot application locally (i.e. $ mvn spring-boot:run on your computer) and on a deployed server.
If you can't get a DENY on both, you need to revisit your application logic and such.
Once you get a DENY, set up a simple policy that takes one parameter. I.E. if someNumber == 2, return PERMIT. Then try this on both your localhost and on Azure. Once you have this working, you are ready to try the policy you mentioned in your question.
FYI I have multiple Spring Boot projects that communicate with a XACML engine (Axiomatics, not WSO2) in my Github, such as: https://github.com/michaelcgood/Axiomatics-Yet-Another-PEP .
I also have multiple articles about Spring Boot on my website: https://michaelcgood.com/category/spring/ . If you have questions about the content or code, you can contact me (info on contact page) and I'll respond as I'm able to.
I have setup ADFS and a NodeJS application to perform single-sign-on using ADFS as IdP.
I receive the SAMLreponse seen below.
When I receive the profile-object inside the verify function setup for the SAML-strategy, I see this:
{"issuer":"http://nonp-adfs.dsgapps.dk/adfs/services/trust"}
I need the profile to include at least the email or user ID of the logged in user.
How can I fix this?
SAMLresponse received:
<samlp:Response Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
Destination="https://localhost:3000/adfs/postResponse" ID="_e543e979-0d99-48fe-947f-1d1469da8c70"
InResponseTo="_49ab1e1060c3d7849902" IssueInstant="2018-06-28T19:46:27.782Z" Version="2.0"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://nonp-adfs.dsgapps.dk/adfs/services/trust</Issuer>
<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
<Assertion ID="_cf245f57-1380-47cd-a5d3-05b13e4d9416" IssueInstant="2018-06-28T19:46:27.782Z"
Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://nonp-adfs.dsgapps.dk/adfs/services/trust</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#_cf245f57-1380-47cd-a5d3-05b13e4d9416">
<ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>r6voAsVq4yAJTn4BQLFsyaoiCK3b7KQbJ5jVqi53ceY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>F55JA6jNp3qFfp7p/BSzQBRTtVPOlQvIfVNG3JiqjohVC7Et0+aiRVlHHvZNghPJxhmxhuAUbo2kOweN+lZKb+fqDgK51kZ/DrIVpkljmwP2gJYgOGpJti53wfH2qkdDsxNkR3e13mG7RKwBuA4gJ0NxUFshmxyun0HKefd10wjnFwHY6dELWFmTL1W5xd2ZF/98ahIaqEWAMCYsJewEg4ND8z4vG74miht3lWHfTJL6kQ0UGkTJVwGZy9L8zaY8AMDRujs8SlXvBx9nvUnvufpYqto4kd0O0USWMCOPipcF2sVYDOVzidRSRb79TK256Wg9EGiw1usVThfAJ8IBzQ==</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIC5DCCAcygAwIBAgIQWKHI7vunT6hIeNtPiejvbTANBgkqhkiG9w0BAQsFADAuMSwwKgYDVQQDEyNBREZTIFNpZ25pbmcgLSBub25wLWFkZnMuZHNnYXBwcy5kazAeFw0xODA2MTUxNDQ4NTdaFw0xOTA2MTUxNDQ4NTdaMC4xLDAqBgNVBAMTI0FERlMgU2lnbmluZyAtIG5vbnAtYWRmcy5kc2dhcHBzLmRrMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyN0SSHVjJML1lmcHB8RBNLXnegEISB66Nc75xEpscFGNPKoQloLck6XLPYvhmiL8WiVHTzghiJpU/faViR7s+wksj3n4IXVfCxb6wMd78LiOfeE6yyED+C/EprwoRWGXncUK4lwfLDGOPbWVqaPy0u14rQR0mvn0BsIOiML1JJvAPtf8fhavNmce2aEeRltLY3N8aoLMw8/TMrG+wk1imUo+JScp3gOPqrDnQBGgcjdBY/EaC9mFfAUbhyly0vKl/gYkOv1HFhUMtH7NlLUmDsvOCt3Nrbf6aKmi+H1EAfwJR/POnMbsoC8sqf4PWk/kMtj1POOpZAnQOBE8u4NtPwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQDIdu6cr7LgoNdXpgtwd/Zt7sb1N6dJ/GgULuxBm7Bm1Mdsc9+Q0lDhxeGtay9AIvpbF67xvSzrCz3eL9xPuNV6BYmZpYFsyBPP4MROlkgq1MkqLDpkB/zkiKQqZiJG3RHl5e+WniFrAmNxuuUAtdhKbh1ADJKc1bxte6uiY0dN/Mfw6WnY3m3VOtae9xoqHNM2i4uhEbMvXV9Pmb8BVv4eIZLtOgo+vgkusp3FZa2PL4UWQIPNiEggIxhs7MfpaoADT4taGeavpHWKuxIGvDQzoe7GP2iDGzyH1kS24rSeJRYOiyBq1zPJHrSPeLFsef/7LapCaz5x5+T/eWPhyJKd</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><SubjectConfirmationData InResponseTo="_49ab1e1060c3d7849902"
NotOnOrAfter="2018-06-28T19:51:27.782Z" Recipient="https://localhost:3000/adfs/postResponse"/></SubjectConfirmation>
</Subject>
<Conditions NotBefore="2018-06-28T19:46:27.781Z" NotOnOrAfter="2018-06-28T20:46:27.781Z">
<AudienceRestriction>
<Audience>acme_tools_com</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2018-06-28T19:45:51.797Z">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
It was very simple. From the Relying Party Trust Menu I could add the claims such as AD properties.
Apologies if these seems like a duplicate but I have been searching through the posts and I cannot find exactly what I am looking for.
My web application is sending an auth request to Azure for Single Sign On. Upon receipt of the response, what field and attributes need to be verified to ensure that the assertions can be trusted and why?
An example response is here from the Microsoft documentation-
<samlp:Response ID="_a4958bfd-e107-4e67-b06d-0d85ade2e76a" Version="2.0" IssueInstant="2013-03-18T07:38:15.144Z" Destination="https://contoso.com/identity/inboundsso.aspx" InResponseTo="id758d0ef385634593a77bdf7e632984b6" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> https://login.microsoftonline.com/82869000-6ad1-48f0-8171-272ed18796e9/</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="_bf9c623d-cc20-407a-9a59-c2d0aee84d12" IssueInstant="2013-03-18T07:38:15.144Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>https://login.microsoftonline.com/82869000-6ad1-48f0-8171-272ed18796e9/</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
</ds:Signature>
<Subject>
<NameID>Uz2Pqz1X7pxe4XLWxV9KJQ+n59d573SepSAkuYKSde8=</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="id758d0ef385634593a77bdf7e632984b6" NotOnOrAfter="2013-03-18T07:43:15.144Z" Recipient="https://contoso.com/identity/inboundsso.aspx" />
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2013-03-18T07:38:15.128Z" NotOnOrAfter="2013-03-18T08:48:15.128Z">
<AudienceRestriction>
<Audience>https://www.contoso.com</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
<AttributeValue>testuser#contoso.com</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
<AttributeValue>3F2504E0-4F89-11D3-9A0C-0305E82C3301</AttributeValue>
</Attribute>
...
</AttributeStatement>
<AuthnStatement AuthnInstant="2013-03-18T07:33:56.000Z" SessionIndex="_bf9c623d-cc20-407a-9a59-c2d0aee84d12">
<AuthnContext>
<AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
What i know so far.
You must verify the signature to ensure the message has not been modified.
You must verify that the certificate public key is from a trusted source or else any validly signed certificate would authenticate.
What else?
The signature - remember to check the references.
Verify that the certificate is from the right peer (as you've noticed yourself)
The Conditions of the assertion.
I'd recommend that you do not write your own code for this and instead use an existing SAML2 SP library. Getting all of this right is a lot of work (I've done it, and I'm not sure I would if I had known how much work it is).
All,
I have my application setup so that i can use a specific username and password combination:
<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/security"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security-3.0.xsd">
<http use-expressions="true" access-denied-page="/start.jsf">
<intercept-url pattern="/start.jsf" filters="none" />
<intercept-url pattern="/web/**" access="isAuthenticated()" />
<form-login login-page="/start.jsf" default-target-url="/web/user/homepage.jsf" authentication-failure-url="/start.jsf?state=failure"/>
<logout logout-success-url="/start.jsf?state=logout" />
</http>
<!-- <authentication-manager alias="authenticationManager">
<authentication-provider>
<password-encoder hash="md5" />
<jdbc-user-service data-source-ref="dataSource"
users-by-username-query="SELECT U.email_address AS username, U.password as password, 'true' as enabled FROM users U where U.email_address=?"
authorities-by-username-query="SELECT U.email_address AS username, 'USER' as authority FROM users U WHERE U.email_address=?"
role-prefix="ROLE_" />
</authentication-provider>
</authentication-manager> -->
<authentication-manager alias="authenticationManager">
<authentication-provider>
<password-encoder hash="md5"/>
<user-service>
<user name="user1" password="a564de63c2d0da68cf47586ee05984d7" authorities="ROLE_SUPERVISOR, ROLE_USER, ROLE_TELLER" />
</user-service>
</authentication-provider>
</authentication-manager>
</beans:beans>
Problem is that when I ask it to goto the dataSource, it cannot find the datasource. Reason for this is I have another ApplicationContext.xml in a config folder where all my java source files are. How do people normally organize the project so that this file is able to pickup the datasource file? I want to setup the project accordingly...thanks for the input!
Also, the login works, however, once the user logs in, I want to be able to get the userid/password and I'm not able to. How is that possible?
Implying that you have 2 XML files (in classpath) with spring context config: main-ctx.xml and security-ctx.xml and your are instantiating your app context using main-ctx.xml.
Then you can include config from security-ctx.xml into app context using this in main-ctx.xml (depends on your files locations path may be different):
<import resource="classpath:security-ctx.xml"/>
So you can define dataSource in main-ctx.xml and use it in security-ctx.xml in authentication-manager configuration.
I have been POC'ing with milestone 2 of the Kerberos extension to achieve single sign-on.
Quick summary of my setup:
KDC: Windows Server 2003 (SP2)
Web server: Ubuntu 10.04, Tomcat 5.5, Java 1.6.0_22 (not on the domain)
Spring: Framework 3.0.5, Security 3.0.4, Kerberos Extension 1.0.0 M2
I have setup my configuration to first attempt SPNEGO authentication and if it fails to then redirect to a login page.
This is done by setting SpnegoAuthenticationProcessingFilter's "failureHandler" property. I have successfully tested this
on Windows machines (XP and 7) that are in and out of the domain. The machines that are outside the domain gets redirected to
the login page and then can successfully login.
Here is my config:
<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:beans="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-3.0.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security-3.0.xsd">
<http entry-point-ref="spnegoEntryPoint" auto-config="false">
<intercept-url pattern="/login*" access="IS_AUTHENTICATED_ANONYMOUSLY" />
<intercept-url pattern="/j_spring_security_check*" access="IS_AUTHENTICATED_ANONYMOUSLY"/>
<intercept-url pattern="/**" access="IS_AUTHENTICATED_FULLY" />
<custom-filter ref="spnegoAuthenticationProcessingFilter" position="BASIC_AUTH_FILTER" />
<form-login login-page="/login.html" default-target-url="/" always-use-default-target="true"/>
</http>
<authentication-manager alias="authenticationManager">
<authentication-provider ref="kerberosServiceAuthenticationProvider" />
<authentication-provider ref="kerberosAuthenticationProvider"/>
</authentication-manager>
<beans:bean id="spnegoEntryPoint"
class="org.springframework.security.extensions.kerberos.web.SpnegoEntryPoint" />
<beans:bean id="spnegoAuthenticationProcessingFilter"
class="org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter">
<beans:property name="failureHandler">
<beans:bean class="org.springframework.security.web.authentication.ExceptionMappingAuthenticationFailureHandler">
<beans:property name="defaultFailureUrl" value="/login.html" />
<beans:property name="allowSessionCreation" value="true"/>
</beans:bean>
</beans:property>
<beans:property name="authenticationManager" ref="authenticationManager" />
</beans:bean>
<beans:bean id="kerberosServiceAuthenticationProvider"
class="org.springframework.security.extensions.kerberos.KerberosServiceAuthenticationProvider">
<beans:property name="ticketValidator">
<beans:bean
class="org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator">
<beans:property name="servicePrincipal" value="HTTP/mywebserver.corpza.corp.co.za"/>
<beans:property name="keyTabLocation" value="classpath:mywebserver.keytab" />
<beans:property name="debug" value="true"/>
</beans:bean>
</beans:property>
<beans:property name="userDetailsService" ref="dummyUserDetailsService" />
</beans:bean>
<beans:bean id="kerberosAuthenticationProvider" class="org.springframework.security.extensions.kerberos.KerberosAuthenticationProvider">
<beans:property name="kerberosClient">
<beans:bean class="org.springframework.security.extensions.kerberos.SunJaasKerberosClient">
<beans:property name="debug" value="true" />
</beans:bean>
</beans:property>
<beans:property name="userDetailsService" ref="dummyUserDetailsService" />
</beans:bean>
<beans:bean class="org.springframework.security.extensions.kerberos.GlobalSunJaasKerberosConfig">
<beans:property name="debug" value="true" />
<beans:property name="krbConfLocation" value="/etc/krb5.conf" />
</beans:bean>
<beans:bean id="dummyUserDetailsService" class="main.server.DummyUserDetailsService"/>
</beans:beans>
When the Windows machine is outside the domain my web server responds with the "WWW-Authenticate Negotiate" header (as per usual) to which
the Windows machine responds to with a NTLM header ("Negotiate TlRM..."), where the SpnegoAuthenticationProcessingFilter then says "Negotiate Header was invalid..."
and awesomly redirects the user to the login page. Great.
The Issue:
There are a number of Mac and Linux machines that are permanently outside the domain which would need to use this web app.
When they hit the web app (with Firefox 3.6) my web server responds with the expected "WWW-Authenticate Negotiate" header to inform
the client that the web app is Kerberized, BUT neither the Mac or Linux machines responds at all. Thus the SpnegoAuthenticationProcessingFilter
doesn't get entered again and hence no failure and subsequently no redirection to the login page takes place.
The Question:
Why doesn't the Mac and Linux machines respond in the same way as the Windows machines (can't belive I just asked that...)?
I know that when the Mac and Linux machines obtain a ticket (via kinit) they are able to authenticated but this doesn't seem like a good solution
at all as it requires effort from the user to provide credentials etc. where the tickets expires as well.
So is there any way that we can get these machines to send back a NTLM header as the Windows machines does?
Or if there are any other suggestions/ways please let me know.
B.t.w. I did configure the Firefoxes that I used on to test on the Mac and Linux machines ("network.negotiate-auth.delegation-uris" and "network.negotiate-auth.trusted-uris" was set to ".corpza.corp.co.za").
It doesn't look like you set network.automatic-ntlm-auth.trusted-uris. Did you read through this?
https://developer.mozilla.org/en/Integrated_Authentication
Grant
You are going the wrong way. Don't rely on the failing SPNEGO filter. The Linux and Mac clients behave correctly just as the Windows client does. The general setup should look like the following, if the filter does not implement/support that, you have found a bug.
Client sends a request to the server
Client receives "401 WWW-Authenticate: Negotiate" from the server (or any combination of Negotiate, Basic, Digest).
Client tries to supply auth data and if it fails it shows the 401 page.
Now you rely on faulty/non-processible data sent from the Windows client to present the form. You should rather send the form with the 401 directly to give all clients the ability to choose an appropriate login method (SPNEGO or form, ie. fail-through). Keep in mind that form auth is not an http auth like Negotiate, Digest or Basic. It has to be treated differently.
We are using that filter too and I am not really happy with it. So I have hands-on experience.