Total Pageviews

Sunday, February 24, 2019

Error: the request specified an assertion consumer service url is not registered in the metadata for the SP

It means your SP metadata dont have correct Assertion Consumer url that client send to IDP

how to get uid when using mod auth mellon for PHP application


 If I add one line to mellon.conf:


MellonUser "uid"

then Apache (or maybe it's Mellon) will populate the $_SERVER['PHP_AUTH_USER'] property that PHP applications need in order to identify a user with the UID from the directory.  That reduces the dependency on headers

forgerock openam error HTTP Status 400 - Error processing AuthnRequest. The receiving entity ID is not valid or not trusted



check your COT or metaAlias   its value might be wrong.

ForgeRocck Logfile information












SSO initiated request type



POST binding
request is in the body

Artifacts Binding
SP send request to IDP, IDP will send HTTP-Artifacts, SP will download artifact from IDP and process it

Http Redirect Binding
Browser Request it is combination to both

OpemAM POST data request flow







Http get will redirect the user to the original request after authentication.

HTTP POST have different flow, original request is in the body of the request that’s why we cant put the original request into goto because OAM  will lose the content of the request. We will still use goto but in this request will not use original request, instead it will point to dummy url and Policy agent will hold the original request. After successful authentican Policy agent will retrive the original cache POST data and Post Form is submitted to browser, browser execute(browser needs to support JavaScript)  self submitted Form and browser will create new POST Request. Now browser have IPlantDirectoryPro cookie.





what cookies are being set up by Forgerock OpenAM


OpenAM set 2 cookies in the browser after the successful user authentication

  "amlbcookie" and  "iPlanetDirectoryPro"

SAML 2.0 X.509 Certification validity requirenment OAM vs OpenAM


OpenAM: During SAML 2.0 request, X.509 certificate don't have to be within validity date. An expired x.509 certificate can work without any issues. It is recommended to have this certificate within a validity date but SAML request won't fail if it is expired.

In Oracle OAM there is a property that can force certificate validity but OpenAM currently don't have this
option.

ADFS intergration thru Kerberos




Currently, the SAML 2 integration uses a PasswordProtectedTransport or "forms-based authentication" authentication context. This authentication context requires the IdP to present users with a form for authentication credentials. With Kerberos, a SAML session is already active through an established Windows login, so the user does not need to authenticate with the IdP.

Procedure
  1. Navigate to Multi-Provider SSO > Identity Providers.
  2. Open the SAML2 Update1 IdP record.
  3. Set the The AuthnContextClassRef method that we will be included in our SAML 2.0 AuthnRequest to the Identity Provider to one of the following:
    AuthnContextClassRef method values
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport (Default)
    urn:federation:authentication:windows
  4. Click Update.

ADFS SAML integration steps






Set up ADFS for SAML

Jakarta
 



This procedure uses ADFS 2.0 and shows samportal.example.com as the ADFS website. Replace this with your ADFS website address.
Before you begin
Role required: admin
Procedure
  1. Log into the ADFS 3.0 server and open the management console.
  2. Right-click Service and choose Edit Federation Service Properties.


    Edit Federation Service Properties
  3. Confirm that the General settings match your DNS entries and certificate names.


    Edit properties
  4. Browse to the certificates and export the Token-Signing certificate.
    1. Right-click the certificate and select View Certificate.
    2. Select the Details tab.
    3. Click Copy to File. The Certificate Export Wizard opens.
    4. Select Next.
    5. Ensure the No, do not export the private key option is selected, and then click Next.
    6. Select DER encoded binary X.509 (.cer), and then click Next.
    7. Select where you want to save the file and give it a name. Click Next.
    8. Select Finish. The instance requires that this certificate be in PEM format. You can convert this certificate using client tools or even online tools such as: SSL Shopper.
  5. Use the DER/Binary certificate that you just created, and export it in Standard PEM format.
Tags: Jakarta, Now Platform Administration, Platform Security




Set up the instance for ADFS

Jakarta
 



After you set up ADFS 2.0 or 3.0, set up the instance and SAML 2.0 settings to work with ADFS.
Before you begin
Role required: admin
Procedure
  1. If not already active, contact Technical Support to activate the SAML 2.0 Single Sign-On plugin.
  2. Configure SAML 2.0, but when you install the IdP certificate, attach the PEM certificate you created when you Set up ADFS for SAML.
  3. Click Save.
  4. Verify that the Issue and Subject fields have values and that there are no errors. If an error occurs, open the saved PEM formatted certificate in Notepad and copy and paste the certificate into the PEM Certificate field.
  5. Verify that the SAML2SingleSignon_update1 installation exit is active.
  6. Continue the SAML 2.0 configuration.
    Note: When a certificate is updated on the ADFS server, you also need to upload an updated certificate to the instance.
Tags: Jakarta, Now Platform Administration, Platform Security



Configure an ADFS relying party

Jakarta
 



At this point you can take the instance metadata and import it into your ADFS server. However, manual configuration of the relying party appears to be easier to implement.
Before you begin
Role required: admin
Procedure
  1. Navigate to SAML 2 Single Sign-on > Properties and verify that the SAML property Sign AuthnRequest (glide.authenticate.sso.saml2.require_signed_authnrequest) is not active. Only keep this property active if your ADFS administrator can verify that you require signed requests.
  2. Copy the metadata that you generated through the SAML 2 metadata link and save it to a file.
  3. Log into the ADFS server and open the management console.
  4. Select Relying Party Trusts.
  5. Select Add Relying Party Trust from the top right corner of the window.
    The add wizard appears.
  6. Click Start to begin.
  7. Use the Import File option to import the metadata file.
  8. Give it a display name such as ServiceNow and enter any notes you want.
  9. Select ADFS 3.0 Profile.
  10. Do not select a token encryption certificate. It will use the certificate that is defined on the service that has already been exported. Defining a certificate here will prevent proper communication with the instance.
  11. Do not enable any settings on the Configure URL.
  12. Enter the instance site to which you connected as the Relying Party trust identifier. In this case usehttps://company.service-now.com and click Add.
  13. Permit all users to access this relying party.
  14. Click Next and clear the Open the Claims when this finishes check box.
  15. Close this page. The new relying party trust appears in the window.
  16. Right-click on the relying party trust and select Properties.
  17. Browse to the Advanced tab and set the Secure hash algorithm to SHA-1.
  18. Browse to the Endpoints tab and add a SAML Assertion Consumer with a Post binding and a URL ofhttps://company.service-now.com/navpage.do.





Configure ADFS relying party claim rules

Jakarta
 



Edit the Claim rules to enable proper communication with the instance.
Before you begin
Role required: admin
Procedure
  1. Log into the ADFS server and open the management console.
  2. Right-click the relying party trust and select Edit Claim Rules.
  3. Click the Issuance Transform Rules tab.
  4. Select Add Rules.
  5. Select Send LDAP Attribute as Claims as the claim rule template to use.
  6. Give the claim a name such as Get LDAP Attributes.
  7. Set the Attribute store to Active Directory, the LDAP Attribute to E-Mail-Addresses, and the Outgoing Claim Type to E-mail Address.


    Get attribute
    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/emailaddress"), 
    query = ";mail;{0}", param = c.Value);
    
  8. Select Finish.
  9. Select Add Rules.
  10. Select Transform an Incoming Claim as the claim rule template to use.
  11. Give the Claim a name such as Email to Name ID.
  12. Set the Incoming claim type to the Outgoing Claim Type in the previous rule. For example, E-Mail Address.
  13. Set the Outgoing claim type to Name ID and the Outgoing name ID format to Email.
    Note: These values must match the Name ID policy you define during SAML 2.0 configuration.
  14. Select Pass through all claim values.


    Email to Name ID
    This claim rule should look similar to the following rule language.
    c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
     => 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:1.1:nameid-format:emailAddress");
    
  15. Click Finish.


Create a SAML logout endpoint

Jakarta
 



Create a SAML logout endpoint to allow single logout.
Before you begin
Role required: admin
About this task
See this article on ADFS signout for more information.
Procedure
  1. Go to ADFS manager > Trust Relationships Relying Party Trusts > properties.
  2. Under the Endpoints tab, click Add.
  3. Configure the settings:
    • Endpoint Type: SAML Logout
    • Binding: POST
    • URLhttps://myadfsserver.domain.net/adfs/ls/?wa=wsignout1.0


Test the ADFS configuration

Jakarta
 



Test your ADFS configuration to verify that it is properly functioning as an identity provider.
Before you begin
Role required: admin
Procedure
  1. Open an Internet Explorer browser.
  2. Navigate to your ADFS portal. For example,https://samportal.example.com/adfs/ls/idpinitiatedsignon.aspx.
    This page contains a drop down list of all configured Relaying Party Trusts.
  3. Select the relaying party associated with your instance.
  4. Click Continue to Sign In.
    If you have configured the SAML 2.0 external authentication properly, you should be automatically logged into the instance.
  5. To test a direct login URL, navigate tohttps://samportal.example.com/adfs/ls/idpinitiatedsignon.aspx?logintoRP=https://company.service-now.com.