I'm reading Azure Active Directory B2C: User migration and having a hard time trying to figure out how to integrate the Technical Profile described there into my custom Sign In policy:
<ClaimsProvider>
<DisplayName>REST APIs</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="LocalAccountSignIn">
<DisplayName>Local account just in time migration</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ServiceUrl">http://{your-app}.azurewebsites.net/api/PrePasswordReset/LoalAccountSignIn</Item>
<Item Key="AuthenticationType">None</Item>
<Item Key="SendClaimsIn">Body</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
<TechnicalProfile Id="LocalAccountPasswordReset">
<DisplayName>Local account just in time migration</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ServiceUrl">http://{your-app}.azurewebsites.net/api/PrePasswordReset/PasswordUpdated</Item>
<Item Key="AuthenticationType">None</Item>
<Item Key="SendClaimsIn">Body</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
I already have a custom SignIn policy called SignInOnlyKMSI. However I'm not sure how to hook that Technical Profile into my policy.
I opened an issue # the repo:
https://github.com/yoelhor/Azure-AD-B2C-UserMigration/issues/2
however I don't think the repo maintainer is active.
They forgot to add the policy files to the repo and the explanation is not that good. It's missing some pieces.
Please use the latest version of the user migration. I moved to the Azure AD B2C community repo.
Yoel
After fiddling with it I got it to work as expected...
In this part in the documentation:
After you define the technical profile for your RESTful API, tell your
Azure AD B2C policy to call the technical profile. The XML snippet
overrides SelfAsserted-LocalAccountSignin-Email, which is defined in
the base policy. The XML snippet also adds ValidationTechnicalProfile,
with ReferenceId pointing to your technical profile
LocalAccountUserMigration.
They tell you WHAT needs to be done but don't actually tell you HOW...
I figured it out. You need to add a new Technical Profile like the following one just below the other two in the same file TrustFrameworkExtensions.xml:
<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
<!-- <OutputClaims>
<OutputClaim ClaimTypeReferenceId="loyaltyNumber" PartnerClaimType="loyaltyNumber" />
</OutputClaims> -->
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="LocalAccountUserMigration" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
Note the <ValidationTechnicalProfile ReferenceId="LocalAccountUserMigration" />. Just rename the 1st technical profile from LocalAccountSignIn to LocalAccountUserMigration.
Related
I am using Sustainsys package Sustainsys.Saml2.AspNetCore2 to build a service provider web app in ASP.NET Core 3.1, which uses Azure B2C as the identity provider using SAML2. I have the following issue:
If I use Sha1 as the signing algorithm, using the option MinIncomingSigningAlgorithm, then an exception is thrown by CryptoConfig.CreateFromName because that method does not know the Sha1 algorithm.
If I use Sha256 as the signing algorithm then Azure B2C signs the response with Sha1 even though I have specified <Item Key="XmlSignatureAlgorithm">Sha256</Item> in the RelyingParty of my custom policy. I should note that this seems to only happen when the service provider starts the single logout flow. The login flow completes without issues and there the signing algorithm is Sha256. Here is my RelyingParty section:
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="XmlSignatureAlgorithm">Sha256</Item>
</Metadata>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
</OutputClaims>
<SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
</TechnicalProfile>
</RelyingParty>
Furthermore, the metadata of Azure B2C uses Sha256 as the signature and digest method. Here is the relevant section:
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="...">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="saml samlp xenc xs"/>
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
</Reference>
</SignedInfo>
Any help is highly appreciated. Thank you.
It turns out that I needed to add <Item Key="XmlSignatureAlgorithm">Sha256</Item> to the tehcnical profile as well (in addition to it being part of RelyingParty as shown above). This solves the issue that I had with single logout.
<TechnicalProfile Id="Saml2AssertionIssuer">
<Protocol Name="None"/>
<OutputTokenFormat>SAML2</OutputTokenFormat>
<Metadata>
<Item Key="XmlSignatureAlgorithm">Sha256</Item>
</Metadata>
</TechnicalProfile>
I have a Liferay 6.1 instance that is connected to LDAP. New users get imported nicely, but when I remove a user from the LDAP directory, Liferay starts throwing exceptions when it tries to sync users from LDAP.
These seem to be safe to ignore, but they produce several megabytes of log and it makes log parsing highly annoying. Also I think it might affect performance. If a deleted user logs in, they see nothing.
16:13:54,422 ERROR [liferay/scheduler_dispatch-790][PortalLDAPImporterImpl:995] LDAP user not found with fullUserDN cn=foobar,ou=people,o=foo,dc=bar,dc=baz
javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn=foobar,ou=people,o=foo,dc=bar,dc=baz'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3057)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2978)
... etc
How could I convince Liferay that this is really OK? Or is there something else I should do?
Until missing users in LDAP are supported by Liferay you can turn off the logging for this particular message. Just create the file ROOT.war/WEB-INF/classes/META-INF/portal-log4j-ext.xml with the following content:
<?xml version="1.0">
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
<!-- Copy all appenders from
ROOT.war/WEB-INF/lib/portal-impl.jar/META-INF/portal-log4j.xml
and add the following filter: -->
<appender ...>
...
<filter class="org.apache.log4j.filter.StringMatchFilter">
<param name="StringToMatch" value="LDAP user not found with fullUserDN" />
<param name="AcceptOnMatch" value="false" />
</filter>
</appender>
<!-- Keep the root definition from portal-log4j.xml
to trigger the parsing of the appenders: -->
<root>
<priority value="INFO" />
<appender-ref ref="CONSOLE" />
<appender-ref ref="FILE" />
</root>
</log4j:configuration>
You can find more about logging in the Liferay Wiki.
In openam I created a subRealm named TestRealm .In order to create policies in TestRealm there should be a referral policy. Im trying to create a policies for TestRealm with the help of ssoadm command, but its throwing a error Cannot create policy. No referral exists to the organization. Im using the following policy.xml to create policies under the root realm.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Policies PUBLIC "-//OpenSSO Policy Administration DTD//EN" "jar://com/sun/identity/policy/policyAdmin.dtd">
<!-- New policy, same as the old policy -->
<Policies>
<Policy name="Test Policy" referralPolicy="false" active="true" >
<Rule name="Test Allow GET with parameters">
<ServiceName name="iPlanetAMWebAgentService" />
<ResourceName name="http://www.test.com/demo/*?*" />
<AttributeValuePair>
<Attribute name="GET" />
<Value>allow</Value>
</AttributeValuePair>
</Rule>
<Rule name="Vidz Ref Allow GET and POST">
<ServiceName name="iPlanetAMWebAgentService" />
<ResourceName name="http://www.test.com/demo/*" />
<AttributeValuePair>
<Attribute name="POST" />
<Value>allow</Value>
</AttributeValuePair>
<AttributeValuePair>
<Attribute name="GET" />
<Value>allow</Value>
</AttributeValuePair>
</Rule>
<Subjects name="Subjects" description="Everybody authenticated">
<Subject name="All Authenticated Users" type="AuthenticatedUsers" includeType="inclusive">
</Subject>
</Subjects>
</Policy>
</Policies>
How to modify the above one to create a referral policy??
The easiest way would be to simply create an example referral in the top level realm, and then just export it via ssoadm for subsequent imports. Also you should use very generic rules in referrals, like http://www.test.demo.com/* and http://www.test.demo.com/*?*, having complex rules in referrals will only slow down policy evaluation without much of a point (the referred policies will be used to make the allow/deny decision in the end anyways).
I'm trying to add Azure Authentication to an existing website with Visual Studio 2013. It looks like this used to be a bit easier in 2012 but seems the recommended path for 2013 is to set this up when creating the project.
I created a new project with AAD (which works) to compare to the changes being made to the project I need to add authentication to. I copied the authentication classes and config settings but it still seems like there is something wrong in web.config:
For AppSettings I have:
<add key="ida:FederationMetadataLocation" value="https://login.windows.net/_____/FederationMetadata/2007-06/FederationMetadata.xml" />
<add key="ida:Realm" value="https://AADPath/Application" />
<add key="ida:AudienceUri" value="https://AADPath/Application" />
For System.identityModel I have:
<system.identityModel>
<identityConfiguration>
<issuerNameRegistry type="RegistryClassPath, ProjectName" />
<audienceUris>
<add value="https://AADPath/Application"/>
</audienceUris>
<securityTokenHandlers>
For system.identityModel.services I have:
<federationConfiguration>
<cookieHandler requireSsl="true" />
<wsFederation passiveRedirectEnabled="true"
issuer="https://login.windows.net/AADPath/wsfed"
realm="https://AADPath/Application"
requireHttps="true" />
When I run the site, I'm redirected to the login page as I expect but after logging in I'm presented with the WIF10201: No valid key mapping found for securityToken error.
It was not the configuration but rather I didn't copy the data from the embedded database to the existing project. All seems to be working now.
I have implemented my website using spring security.
I have added default-target-url in form-login tag:
<security:form-login login-page="/pages/dashboard.action" default-target-url="/welcome.action" authentication-failure-url="/pages/dashboard.action?error=true" />
So when ever user successfully logs in it will be redirected to the page which is defined by mapping given in default-target-url.
But I dont want this, I have log-in button at many places and i want user to directed to the same page from where he is logging in.
Can any one help me with this?
my dispather-servlet.xml:
<security:http use-expressions="true">
<security:intercept-url pattern="/IGG/citizen/*" access="hasRole('IGG_CITIZEN')" />
<security:form-login login-page="/pages/dashboard.action" default-target-url="/welcome.action" authentication-failure-url="/pages/dashboard.action?error=true" />
<security:logout logout-success-url="/pages/dashboard.action" delete-cookies="JSESSIONID" />
<security:anonymous username="guest" granted-authority="ROLE_GUEST"/>
<security:session-management invalid-session-url="/pages/dashboard.action"/>
<security:remember-me/>
<security:access-denied-handler delete-cookies="JSESSIONID"/>
</security:http>
Use bean SavedRequestAwareAuthenticationSuccessHandler as your success handler:
<bean id="successHandler"
class="org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler"
<property name="defaultTargetUrl" value="/welcome.action"/>
</bean>
And refer to it from the form-login using authentication-success-handler-ref parameter:
<security:form-login authentication-success-handler-ref="successHandler"/>
The SavedRequestAwareAuthenticationSuccessHandler uses page which user tried to access before initialization of the authentication process as the default landing page. When it's not available the defaultTargetUrl is used instead. The "stored page" value is set inside ExceptionTranslationFilter.